From 4432382693f4e824f2fd5e482692c33772b7568a Mon Sep 17 00:00:00 2001
From: Clair Blacketer <mblacke@its.jnj.com>
Date: Wed, 8 Feb 2023 15:04:22 -0500
Subject: [PATCH] Minor updates to package

This release has some minor bugfixes and updates to the rmd files
---
 .gitignore                                    |    1 +
 DESCRIPTION                                   |    2 +-
 docs/background.html                          |  140 +-
 docs/cdm30.html                               |   21 +-
 docs/cdm53.html                               | 2414 ++++++++++++---
 docs/cdm531.html                              |   28 +-
 docs/cdm54.html                               | 2753 +++++++++++++----
 docs/cdm54Changes.html                        |   58 +-
 docs/cdm60.html                               | 2628 +++++++++++++---
 docs/cdmDecisionTree.html                     |   37 +-
 docs/cdmPrivacy.html                          |  329 +-
 docs/cdmRPackage.html                         |   27 +-
 docs/cdmRefreshProcess.html                   |  105 +-
 docs/cdmRequestProcess.html                   |  148 +-
 docs/contactVocab.html                        |   37 +-
 docs/contribute.html                          |   33 +-
 docs/dataModelConventions.html                |  645 +++-
 docs/download.html                            |   36 +-
 docs/drug_dose.html                           |   99 +-
 docs/ehrObsPeriods.html                       |  141 +-
 docs/faq.html                                 |  446 ++-
 docs/index.html                               |   16 +-
 docs/indices-primary-foreign.html             |   74 +-
 docs/leaveAsIs.html                           |   26 +-
 docs/localChange.html                         |   26 +-
 docs/networkUseCase.html                      |   25 +-
 docs/oncology.html                            |   83 +-
 docs/queries.html                             |   38 +-
 docs/reviewProposals.html                     |   23 +-
 .../header-attrs-2.13/header-attrs.js         |   12 -
 docs/sqlScripts.html                          |   71 +-
 docs/useCaseN.html                            |   29 +-
 docs/useCaseY.html                            |   28 +-
 docs/vocabN.html                              |   29 +-
 docs/vocabRequest.html                        |   36 +-
 docs/vocabY.html                              |   22 +-
 docs/vocabulary.html                          |  296 +-
 extras/codeToRun.R                            |    6 +-
 .../OMOPCDM_bigquery_5.4_constraints.sql      |  176 --
 .../5.4/bigquery/OMOPCDM_bigquery_5.4_ddl.sql |  145 +-
 .../bigquery/OMOPCDM_bigquery_5.4_indices.sql |   60 -
 .../OMOPCDM_bigquery_5.4_primary_keys.sql     |   28 -
 .../impala/OMOPCDM_impala_5.4_constraints.sql |  176 --
 .../ddl/5.4/impala/OMOPCDM_impala_5.4_ddl.sql |   39 -
 .../5.4/impala/OMOPCDM_impala_5.4_indices.sql |   60 -
 .../OMOPCDM_impala_5.4_primary_keys.sql       |   28 -
 .../OMOPCDM_netezza_5.4_constraints.sql       |  176 --
 .../5.4/netezza/OMOPCDM_netezza_5.4_ddl.sql   |   39 -
 .../netezza/OMOPCDM_netezza_5.4_indices.sql   |   60 -
 .../OMOPCDM_netezza_5.4_primary_keys.sql      |   28 -
 .../oracle/OMOPCDM_oracle_5.4_constraints.sql |  176 --
 .../ddl/5.4/oracle/OMOPCDM_oracle_5.4_ddl.sql |   39 -
 .../5.4/oracle/OMOPCDM_oracle_5.4_indices.sql |   60 -
 .../OMOPCDM_oracle_5.4_primary_keys.sql       |   28 -
 .../5.4/pdw/OMOPCDM_pdw_5.4_constraints.sql   |  176 --
 inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_ddl.sql      |  117 +-
 inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_indices.sql  |   60 -
 .../5.4/pdw/OMOPCDM_pdw_5.4_primary_keys.sql  |   28 -
 .../OMOPCDM_postgresql_5.4_constraints.sql    |  176 --
 .../postgresql/OMOPCDM_postgresql_5.4_ddl.sql |   39 -
 .../OMOPCDM_postgresql_5.4_indices.sql        |   60 -
 .../OMOPCDM_postgresql_5.4_primary_keys.sql   |   28 -
 .../OMOPCDM_redshift_5.4_constraints.sql      |  176 --
 .../5.4/redshift/OMOPCDM_redshift_5.4_ddl.sql |   39 -
 .../redshift/OMOPCDM_redshift_5.4_indices.sql |   60 -
 .../OMOPCDM_redshift_5.4_primary_keys.sql     |   28 -
 .../OMOPCDM_snowflake_5.4_constraints.sql     |   37 +-
 .../snowflake/OMOPCDM_snowflake_5.4_ddl.sql   |  918 +++---
 .../OMOPCDM_snowflake_5.4_indices.sql         |   97 +
 .../OMOPCDM_snowflake_5.4_primary_keys.sql    |    5 +-
 inst/ddl/5.4/spark/OMOPCDM_spark_5.4_ddl.sql  |  351 ++-
 .../5.4/spark/OMOPCDM_spark_5.4_indices.sql   |   32 -
 .../OMOPCDM_synapse_5.4_constraints.sql       |  178 +-
 .../5.4/synapse/OMOPCDM_synapse_5.4_ddl.sql   |  933 +++---
 .../synapse/OMOPCDM_synapse_5.4_indices.sql   |   84 +-
 .../OMOPCDM_synapse_5.4_primary_keys.sql      |   86 +-
 man/createDdl.Rd                              |    6 +-
 man/writeDdl.Rd                               |   11 +-
 rmd/cdm53.Rmd                                 |    2 +-
 rmd/cdm54.Rmd                                 |    2 +-
 rmd/cdm60.Rmd                                 |    2 +-
 81 files changed, 10361 insertions(+), 5656 deletions(-)
 delete mode 100644 docs/site_libs/header-attrs-2.13/header-attrs.js

diff --git a/.gitignore b/.gitignore
index c6348106..3d582222 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ ehthumbs.db
 Thumbs.db
 extras/codeToRun.R
 output/
+ddl/
diff --git a/DESCRIPTION b/DESCRIPTION
index 9e8b93e4..5ec34b2b 100644
--- a/DESCRIPTION
+++ b/DESCRIPTION
@@ -24,5 +24,5 @@ Suggests:
     RSQLite,
     withr
 NeedsCompilation: no
-RoxygenNote: 7.1.1
+RoxygenNote: 7.2.1
 Config/testthat/edition: 3
diff --git a/docs/background.html b/docs/background.html
index 56faabae..fab210ce 100644
--- a/docs/background.html
+++ b/docs/background.html
@@ -11,9 +11,9 @@
 
 
 
-<title>background.knit</title>
+<title> OMOP CDM Background</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -487,46 +491,118 @@
 
 
 
-<h1 class="title toc-ignore"><div>
-<img src="ohdsi40x40.png"></img> OMOP CDM Background
-</div></h1>
+<h1 class="title toc-ignore"><img src="ohdsi40x40.png"></img> OMOP CDM
+Background</h1>
 
 </div>
 
 
 <div id="background" class="section level2">
 <h2>Background</h2>
-<p>The Observational Medical Outcomes Partnership (OMOP) was a public-private partnership established to inform the appropriate use of observational healthcare databases for studying the effects of medical products. Over the course of the 5-year project and through its community of researchers from industry, government, and academia, OMOP successfully achieved its aims to:</p>
+<p>The Observational Medical Outcomes Partnership (OMOP) was a
+public-private partnership established to inform the appropriate use of
+observational healthcare databases for studying the effects of medical
+products. Over the course of the 5-year project and through its
+community of researchers from industry, government, and academia, OMOP
+successfully achieved its aims to:</p>
 <ul>
-<li>Conduct methodological research to empirically evaluate the performance of various analytical methods on their ability to identify true associations and avoid false findings</li>
-<li>Develop tools and capabilities for transforming, characterizing, and analysing disparate data sources across the health care delivery spectrum</li>
-<li>Establish a shared resource so that the broader research community can collaboratively advance the science</li>
+<li>Conduct methodological research to empirically evaluate the
+performance of various analytical methods on their ability to identify
+true associations and avoid false findings</li>
+<li>Develop tools and capabilities for transforming, characterizing, and
+analysing disparate data sources across the health care delivery
+spectrum</li>
+<li>Establish a shared resource so that the broader research community
+can collaboratively advance the science</li>
 </ul>
-<p>The results of OMOP’s research has been widely published and presented at scientific conferences, including <a href="https://www.ohdsi.org/2021-ohdsi-global-symposium-info/">annual symposia</a>.</p>
+<p>The results of OMOP’s research has been widely published and
+presented at scientific conferences, including <a
+href="https://www.ohdsi.org/2021-ohdsi-global-symposium-info/">annual
+symposia</a>.</p>
 <p>The OMOP Legacy continues…</p>
-<p>The community is actively using the OMOP Common Data Model for their various research purposes. Those tools will continue to be maintained and supported, and information about this work is available in the <a href="http://www.github.com/ohdsi">public domain</a>.</p>
-<p>The OMOP Common Data Model will continue to be an open-source community standard for observational healthcare data. The model specifications and associated work products will be placed in the public domain, and the entire research community is encouraged to use these tools to support everybody’s own research activities.</p>
+<p>The community is actively using the OMOP Common Data Model for their
+various research purposes. Those tools will continue to be maintained
+and supported, and information about this work is available in the <a
+href="http://www.github.com/ohdsi">public domain</a>.</p>
+<p>The OMOP Common Data Model will continue to be an open-source
+community standard for observational healthcare data. The model
+specifications and associated work products will be placed in the public
+domain, and the entire research community is encouraged to use these
+tools to support everybody’s own research activities.</p>
 </div>
 <div id="the-role-of-the-common-data-model" class="section level2">
 <h2>The Role of the Common Data Model</h2>
-<p>No single observational data source provides a comprehensive view of the clinical data a patient accumulates while receiving healthcare, and therefore none can be sufficient to meet all expected outcome analysis needs. This explains the need for assessing and analyzing multiple data sources concurrently using a common data standard. This standard is provided by the OMOP Common Data Model (CDM).</p>
-<p>The CDM is designed to support the conduct of research to identify and evaluate associations between interventions (drug exposure, procedures, healthcare policy changes etc.) and outcomes caused by these interventions (condition occurrences, procedures, drug exposure etc.). Outcomes can be efficacious (benefit) or adverse (safety risk). Often times, specific patient cohorts (e.g., those taking a certain drug or suffering from a certain disease) may be defined for treatments or outcomes, using clinical events (diagnoses, observations, procedures, etc.) that occur in predefined temporal relationships to each other. The CDM, combined with its standardized content (via the Standardized Vocabularies), will ensure that research methods can be systematically applied to produce meaningfully comparable and reproducible results.</p>
+<p>No single observational data source provides a comprehensive view of
+the clinical data a patient accumulates while receiving healthcare, and
+therefore none can be sufficient to meet all expected outcome analysis
+needs. This explains the need for assessing and analyzing multiple data
+sources concurrently using a common data standard. This standard is
+provided by the OMOP Common Data Model (CDM).</p>
+<p>The CDM is designed to support the conduct of research to identify
+and evaluate associations between interventions (drug exposure,
+procedures, healthcare policy changes etc.) and outcomes caused by these
+interventions (condition occurrences, procedures, drug exposure etc.).
+Outcomes can be efficacious (benefit) or adverse (safety risk). Often
+times, specific patient cohorts (e.g., those taking a certain drug or
+suffering from a certain disease) may be defined for treatments or
+outcomes, using clinical events (diagnoses, observations, procedures,
+etc.) that occur in predefined temporal relationships to each other. The
+CDM, combined with its standardized content (via the Standardized
+Vocabularies), will ensure that research methods can be systematically
+applied to produce meaningfully comparable and reproducible results.</p>
 </div>
 <div id="design-principles" class="section level2">
 <h2>Design Principles</h2>
-<p>The CDM is designed to include all observational health data elements (experiences of the patient receiving health care) that are relevant for analytic use cases to support the generation of reliable scientific evidence about disease natural history, healthcare delivery, effects of medical interventions, the identification of demographic information, health care interventions and outcomes.</p>
-<p>Therefore, the CDM is designed to store observational data to allow for research, under the following principles:</p>
+<p>The CDM is designed to include all observational health data elements
+(experiences of the patient receiving health care) that are relevant for
+analytic use cases to support the generation of reliable scientific
+evidence about disease natural history, healthcare delivery, effects of
+medical interventions, the identification of demographic information,
+health care interventions and outcomes.</p>
+<p>Therefore, the CDM is designed to store observational data to allow
+for research, under the following principles:</p>
 <ul>
-<li><strong>Suitability for purpose:</strong> The CDM aims to provide data organized in a way optimal for analysis, rather than for the purpose of addressing the operational needs of health care providers or payers.</li>
-<li><strong>Data protection:</strong> All data that might jeopardize the identity and protection of patients, such as names, precise birthdays etc. are limited. Exceptions are possible where the research expressly requires more detailed information, such as precise birth dates for the study of infants.</li>
-<li><strong>Design of domains:</strong> The domains are modeled in a person-centric relational data model, where for each record the identity of the person and a date is captured as a minimum.</li>
-<li><strong>Rationale for domains:</strong> Domains are identified and separately defined in an entity-relationship model if they have an analysis use case and the domain has specific attributes that are not otherwise applicable. All other data can be preserved as an observation in an entity-attribute-value structure.</li>
-<li><strong>Standardized Vocabularies:</strong> To standardize the content of those records, the CDM relies on the Standardized Vocabularies containing all necessary and appropriate corresponding standard healthcare concepts.</li>
-<li><strong>Reuse of existing vocabularies:</strong> If possible, these concepts are leveraged from national or industry standardization or vocabulary definition organizations or initiatives, such as the National Library of Medicine, the Department of Veterans’ Affairs, the Center of Disease Control and Prevention, etc.</li>
-<li><strong>Maintaining source codes:</strong> Even though all codes are mapped to the Standardized Vocabularies, the model also stores the original source code to ensure no information is lost.</li>
-<li><strong>Technology neutrality:</strong> The CDM does not require a specific technology. It can be realized in any relational database, such as Oracle, SQL Server etc., or as SAS analytical datasets.</li>
-<li><strong>Scalability:</strong> The CDM is optimized for data processing and computational analysis to accommodate data sources that vary in size, including databases with up to hundreds of millions of persons and billions of clinical observations.</li>
-<li><strong>Backwards compatibility:</strong> All changes from previous CDMs are clearly delineated in the <a href="https://github.com/OHDSI/CommonDataModel">github repository</a>. Older versions of the CDM can be easily created from the CDMv5, and no information is lost that was present previously.</li>
+<li><strong>Suitability for purpose:</strong> The CDM aims to provide
+data organized in a way optimal for analysis, rather than for the
+purpose of addressing the operational needs of health care providers or
+payers.</li>
+<li><strong>Data protection:</strong> All data that might jeopardize the
+identity and protection of patients, such as names, precise birthdays
+etc. are limited. Exceptions are possible where the research expressly
+requires more detailed information, such as precise birth dates for the
+study of infants.</li>
+<li><strong>Design of domains:</strong> The domains are modeled in a
+person-centric relational data model, where for each record the identity
+of the person and a date is captured as a minimum.</li>
+<li><strong>Rationale for domains:</strong> Domains are identified and
+separately defined in an entity-relationship model if they have an
+analysis use case and the domain has specific attributes that are not
+otherwise applicable. All other data can be preserved as an observation
+in an entity-attribute-value structure.</li>
+<li><strong>Standardized Vocabularies:</strong> To standardize the
+content of those records, the CDM relies on the Standardized
+Vocabularies containing all necessary and appropriate corresponding
+standard healthcare concepts.</li>
+<li><strong>Reuse of existing vocabularies:</strong> If possible, these
+concepts are leveraged from national or industry standardization or
+vocabulary definition organizations or initiatives, such as the National
+Library of Medicine, the Department of Veterans’ Affairs, the Center of
+Disease Control and Prevention, etc.</li>
+<li><strong>Maintaining source codes:</strong> Even though all codes are
+mapped to the Standardized Vocabularies, the model also stores the
+original source code to ensure no information is lost.</li>
+<li><strong>Technology neutrality:</strong> The CDM does not require a
+specific technology. It can be realized in any relational database, such
+as Oracle, SQL Server etc., or as SAS analytical datasets.</li>
+<li><strong>Scalability:</strong> The CDM is optimized for data
+processing and computational analysis to accommodate data sources that
+vary in size, including databases with up to hundreds of millions of
+persons and billions of clinical observations.</li>
+<li><strong>Backwards compatibility:</strong> All changes from previous
+CDMs are clearly delineated in the <a
+href="https://github.com/OHDSI/CommonDataModel">github repository</a>.
+Older versions of the CDM can be easily created from the CDMv5, and no
+information is lost that was present previously.</li>
 </ul>
 </div>
 
diff --git a/docs/cdm30.html b/docs/cdm30.html
index 19da13e9..36ee7e7b 100644
--- a/docs/cdm30.html
+++ b/docs/cdm30.html
@@ -13,7 +13,7 @@
 
 <title>CDM v3</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -492,7 +496,8 @@ <h1 class="title toc-ignore">CDM v3</h1>
 </div>
 
 
-<p>You can find the specification for CDM v3 at this <a href="https://forums.ohdsi.org/uploads/default/original/1X/2d8b44ea1ee0f9f70427dd2c7332335b8eb6a073.docx">link</a>.</p>
+<p>You can find the specification for CDM v3 at this <a
+href="https://forums.ohdsi.org/uploads/default/original/1X/2d8b44ea1ee0f9f70427dd2c7332335b8eb6a073.docx">link</a>.</p>
 
 
 
diff --git a/docs/cdm53.html b/docs/cdm53.html
index 348eff6f..be828f0a 100644
--- a/docs/cdm53.html
+++ b/docs/cdm53.html
@@ -13,7 +13,7 @@
 
 <title>OMOP CDM v5.3</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -492,19 +496,40 @@ <h1 class="title toc-ignore"><strong>OMOP CDM v5.3</strong></h1>
 </div>
 
 
-<p>Below is the specification document for the OMOP Common Data Model, v5.3 (previously v5.3.1). Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the <a href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a> page.</p>
-<p><em><strong>Special Note</strong> This documentation previously referenced v5.3.1. During the OHDSI/CommonDataModel Hack-A-Thon that occurred on August 18, 2021 the decision was made to align documentation with the minor releases. Hot fixes and minor.minor release can be found through the searching of tags.</em></p>
-<p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm documentation link to forum on doc page</p>
+<p>Below is the specification document for the OMOP Common Data Model,
+v5.3 (previously v5.3.1). Each table is represented with a high-level
+description and ETL conventions that should be followed. This is
+continued with a discussion of each field in each table, any conventions
+related to the field, and constraints that should be followed (like
+primary key, foreign key, etc). Should you have questions please feel
+free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the
+<a href="https://github.com/ohdsi/CommonDataModel/issues">github
+issue</a> page.</p>
+<p><em><strong>Special Note</strong> This documentation previously
+referenced v5.3.1. During the OHDSI/CommonDataModel Hack-A-Thon that
+occurred on August 18, 2021 the decision was made to align documentation
+with the minor releases. Hot fixes and minor.minor release can be found
+through the searching of tags.</em></p>
+<p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm
+documentation link to forum on doc page</p>
 <div id="clinical-data-tables" class="section level2">
 <h2><strong>Clinical Data Tables</strong></h2>
 <div id="person" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PERSON</h3>
 <p><strong>Table Description</strong></p>
-<p>This table serves as the central identity management for all Persons in the database. It contains records that uniquely identify each person or patient, and some demographic information.</p>
+<p>This table serves as the central identity management for all Persons
+in the database. It contains records that uniquely identify each person
+or patient, and some demographic information.</p>
 <p><strong>User Guide</strong></p>
 <p>All records in this table are independent Persons.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>All Persons in a database needs one record in this table, unless they fail data quality requirements specified in the ETL. Persons with no Events should have a record nonetheless. If more than one data source contributes Events to the database, Persons must be reconciled, if possible, across the sources to create one single record per Person. The content of the BIRTH_DATETIME must be equivalent to the content of BIRTH_DAY, BIRTH_MONTH and BIRTH_YEAR.</p>
+<p>All Persons in a database needs one record in this table, unless they
+fail data quality requirements specified in the ETL. Persons with no
+Events should have a record nonetheless. If more than one data source
+contributes Events to the database, Persons must be reconciled, if
+possible, across the sources to create one single record per Person. The
+content of the BIRTH_DATETIME must be equivalent to the content of
+BIRTH_DAY, BIRTH_MONTH and BIRTH_YEAR.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -543,10 +568,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 person_id
 </td>
 <td style="text-align:left;">
-It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently.
+It is assumed that every person with a different unique identifier is in
+fact a different person and should be treated independently.
 </td>
 <td style="text-align:left;">
-Any person linkage that needs to occur to uniquely identify Persons ought to be done prior to writing this table. This identifier can be the original id from the source data provided if it is an integer, otherwise it can be an autogenerated number.
+Any person linkage that needs to occur to uniquely identify Persons
+ought to be done prior to writing this table. This identifier can be the
+original id from the source data provided if it is an integer, otherwise
+it can be an autogenerated number.
 </td>
 <td style="text-align:left;">
 integer
@@ -570,10 +599,17 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 gender_concept_id
 </td>
 <td style="text-align:left;">
-This field is meant to capture the biological sex at birth of the Person. This field should not be used to study gender identity issues.
+This field is meant to capture the biological sex at birth of the
+Person. This field should not be used to study gender identity issues.
 </td>
 <td style="text-align:left;">
-Use the gender or sex value present in the data under the assumption that it is the biological sex at birth. If the source data captures gender identity it should be stored in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted gender concepts</a>
+Use the gender or sex value present in the data under the assumption
+that it is the biological sex at birth. If the source data captures
+gender identity it should be stored in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a>
+table. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+gender concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -602,7 +638,10 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Compute age using year_of_birth.
 </td>
 <td style="text-align:left;">
-For data sources with date of birth, the year should be extracted. For data sources where the year of birth is not available, the approximate year of birth could be derived based on age group categorization, if available.
+For data sources with date of birth, the year should be extracted. For
+data sources where the year of birth is not available, the approximate
+year of birth could be derived based on age group categorization, if
+available.
 </td>
 <td style="text-align:left;">
 integer
@@ -628,7 +667,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-For data sources that provide the precise date of birth, the month should be extracted and stored in this field.
+For data sources that provide the precise date of birth, the month
+should be extracted and stored in this field.
 </td>
 <td style="text-align:left;">
 integer
@@ -654,7 +694,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-For data sources that provide the precise date of birth, the day should be extracted and stored in this field.
+For data sources that provide the precise date of birth, the day should
+be extracted and stored in this field.
 </td>
 <td style="text-align:left;">
 integer
@@ -680,7 +721,15 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This field is not required but highly encouraged. For data sources that provide the precise datetime of birth, that value should be stored in this field. If birth_datetime is not provided in the source, use the following logic to infer the date: If day_of_birth is null and month_of_birth is not null then use the first of the month in that year. If month_of_birth is null or if day_of_birth AND month_of_birth are both null and the person has records during their year of birth then use the date of the earliest record, otherwise use the 15th of June of that year. If time of birth is not given use midnight (00:00:0000).
+This field is not required but highly encouraged. For data sources that
+provide the precise datetime of birth, that value should be stored in
+this field. If birth_datetime is not provided in the source, use the
+following logic to infer the date: If day_of_birth is null and
+month_of_birth is not null then use the first of the month in that year.
+If month_of_birth is null or if day_of_birth AND month_of_birth are both
+null and the person has records during their year of birth then use the
+date of the earliest record, otherwise use the 15th of June of that
+year. If time of birth is not given use midnight (00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -707,7 +756,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 This field captures race or ethnic background of the person.
 </td>
 <td style="text-align:left;">
-Only use this field if you have information about race or ethnic background. The Vocabulary contains Concepts about the main races and ethnic backgrounds in a hierarchical system. Due to the imprecise nature of human races and ethnic backgrounds, this is not a perfect system. Mixed races are not supported. If a clear race or ethnic background cannot be established, use Concept_Id 0. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Race&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Race Concepts</a>.
+Only use this field if you have information about race or ethnic
+background. The Vocabulary contains Concepts about the main races and
+ethnic backgrounds in a hierarchical system. Due to the imprecise nature
+of human races and ethnic backgrounds, this is not a perfect system.
+Mixed races are not supported. If a clear race or ethnic background
+cannot be established, use Concept_Id 0. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Race&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Race Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -733,10 +789,17 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 ethnicity_concept_id
 </td>
 <td style="text-align:left;">
-This field captures Ethnicity as defined by the Office of Management and Budget (OMB) of the US Government: it distinguishes only between “Hispanic” and “Not Hispanic”. Races and ethnic backgrounds are not stored here.
+This field captures Ethnicity as defined by the Office of Management and
+Budget (OMB) of the US Government: it distinguishes only between
+“Hispanic” and “Not Hispanic”. Races and ethnic backgrounds are not
+stored here.
 </td>
 <td style="text-align:left;">
-Only use this field if you have US-based data and a source of this information. Do not attempt to infer Ethnicity from the race or ethnic background of the Person. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Ethnicity&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted ethnicity concepts</a>
+Only use this field if you have US-based data and a source of this
+information. Do not attempt to infer Ethnicity from the race or ethnic
+background of the Person. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Ethnicity&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+ethnicity concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -762,10 +825,18 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 location_id
 </td>
 <td style="text-align:left;">
-The location refers to the physical address of the person. This field should capture the last known location of the person.
+The location refers to the physical address of the person. This field
+should capture the last known location of the person.
 </td>
 <td style="text-align:left;">
-Put the location_id from the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a> table here that represents the most granular location information for the person. This could represent anything from postal code or parts thereof, state, or county for example. Since many databases contain deidentified data, it is common that the precision of the location is reduced to prevent re-identification. This field should capture the last known location.
+Put the location_id from the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a>
+table here that represents the most granular location information for
+the person. This could represent anything from postal code or parts
+thereof, state, or county for example. Since many databases contain
+deidentified data, it is common that the precision of the location is
+reduced to prevent re-identification. This field should capture the last
+known location.
 </td>
 <td style="text-align:left;">
 integer
@@ -790,10 +861,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The Provider refers to the last known primary care provider (General Practitioner).
+The Provider refers to the last known primary care provider (General
+Practitioner).
 </td>
 <td style="text-align:left;">
-Put the provider_id from the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#provider">PROVIDER</a> table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here.
+Put the provider_id from the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#provider">PROVIDER</a>
+table of the last known general practitioner of the person. If there are
+multiple providers, it is up to the ETL to decide which to put here.
 </td>
 <td style="text-align:left;">
 integer
@@ -818,7 +893,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-The Care Site refers to where the Provider typically provides the primary care.
+The Care Site refers to where the Provider typically provides the
+primary care.
 </td>
 <td style="text-align:left;">
 </td>
@@ -845,10 +921,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 person_source_value
 </td>
 <td style="text-align:left;">
-Use this field to link back to persons in the source data. This is typically used for error checking of ETL logic.
+Use this field to link back to persons in the source data. This is
+typically used for error checking of ETL logic.
 </td>
 <td style="text-align:left;">
-Some use cases require the ability to link back to persons in the source data. This field allows for the storing of the person value as it appears in the source. This field is not required but strongly recommended.
+Some use cases require the ability to link back to persons in the source
+data. This field allows for the storing of the person value as it
+appears in the source. This field is not required but strongly
+recommended.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -872,7 +952,9 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 gender_source_value
 </td>
 <td style="text-align:left;">
-This field is used to store the biological sex of the person from the source data. It is not intended for use in standard analytics but for reference only.
+This field is used to store the biological sex of the person from the
+source data. It is not intended for use in standard analytics but for
+reference only.
 </td>
 <td style="text-align:left;">
 Put the biological sex of the person as it appears in the source data.
@@ -902,7 +984,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes biological sex in a non-standard vocabulary, store the concept_id here.
+If the source data codes biological sex in a non-standard vocabulary,
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -927,7 +1010,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 race_source_value
 </td>
 <td style="text-align:left;">
-This field is used to store the race of the person from the source data. It is not intended for use in standard analytics but for reference only.
+This field is used to store the race of the person from the source data.
+It is not intended for use in standard analytics but for reference only.
 </td>
 <td style="text-align:left;">
 Put the race of the person as it appears in the source data.
@@ -957,7 +1041,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes race in an OMOP supported vocabulary store the concept_id here.
+If the source data codes race in an OMOP supported vocabulary store the
+concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -982,10 +1067,13 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 ethnicity_source_value
 </td>
 <td style="text-align:left;">
-This field is used to store the ethnicity of the person from the source data. It is not intended for use in standard analytics but for reference only.
+This field is used to store the ethnicity of the person from the source
+data. It is not intended for use in standard analytics but for reference
+only.
 </td>
 <td style="text-align:left;">
-If the person has an ethnicity other than the OMB standard of “Hispanic” or “Not Hispanic” store that value from the source data here.
+If the person has an ethnicity other than the OMB standard of “Hispanic”
+or “Not Hispanic” store that value from the source data here.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1012,7 +1100,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes ethnicity in an OMOP supported vocabulary, store the concept_id here.
+If the source data codes ethnicity in an OMOP supported vocabulary,
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -1038,11 +1127,44 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <div id="observation_period" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains records which define spans of time during which two conditions are expected to hold: (i) Clinical Events that happened to the Person are recorded in the Event tables, and (ii) absense of records indicate such Events did not occur during this span of time.</p>
+<p>This table contains records which define spans of time during which
+two conditions are expected to hold: (i) Clinical Events that happened
+to the Person are recorded in the Event tables, and (ii) absense of
+records indicate such Events did not occur during this span of time.</p>
 <p><strong>User Guide</strong></p>
-<p>For each Person, one or more OBSERVATION_PERIOD records may be present, but they will not overlap or be back to back to each other. Events may exist outside all of the time spans of the OBSERVATION_PERIOD records for a patient, however, absence of an Event outside these time spans cannot be construed as evidence of absence of an Event. Incidence or prevalence rates should only be calculated for the time of active OBSERVATION_PERIOD records. When constructing cohorts, outside Events can be used for inclusion criteria definition, but without any guarantee for the performance of these criteria. Also, OBSERVATION_PERIOD records can be as short as a single day, greatly disturbing the denominator of any rate calculation as part of cohort characterizations. To avoid that, apply minimal observation time as a requirement for any cohort definition.</p>
+<p>For each Person, one or more OBSERVATION_PERIOD records may be
+present, but they will not overlap or be back to back to each other.
+Events may exist outside all of the time spans of the OBSERVATION_PERIOD
+records for a patient, however, absence of an Event outside these time
+spans cannot be construed as evidence of absence of an Event. Incidence
+or prevalence rates should only be calculated for the time of active
+OBSERVATION_PERIOD records. When constructing cohorts, outside Events
+can be used for inclusion criteria definition, but without any guarantee
+for the performance of these criteria. Also, OBSERVATION_PERIOD records
+can be as short as a single day, greatly disturbing the denominator of
+any rate calculation as part of cohort characterizations. To avoid that,
+apply minimal observation time as a requirement for any cohort
+definition.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrollment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
+<p>Each Person needs to have at least one OBSERVATION_PERIOD record,
+which should represent time intervals with a high capture rate of
+Clinical Events. Some source data have very similar concepts, such as
+enrollment periods in insurance claims data. In other source data such
+as most EHR systems these time spans need to be inferred under a set of
+assumptions. It is the discretion of the ETL developer to define these
+assumptions. In many ETL solutions the start date of the first
+occurrence or the first high quality occurrence of a Clinical Event
+(Condition, Drug, Procedure, Device, Measurement, Visit) is defined as
+the start of the OBSERVATION_PERIOD record, and the end date of the last
+occurrence of last high quality occurrence of a Clinical Event, or the
+end of the database period becomes the end of the OBSERVATOIN_PERIOD for
+each Person. If a Person only has a single Clinical Event the
+OBSERVATION_PERIOD record can be as short as one day. Depending on these
+definitions it is possible that Clinical Events fall outside the time
+spans defined by OBSERVATION_PERIOD records. Family history or history
+of Clinical Events generally are not used to generate OBSERVATION_PERIOD
+records around the time they are referring to. Any two overlapping or
+adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -1081,10 +1203,12 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 observation_period_id
 </td>
 <td style="text-align:left;">
-A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id.
+A Person can have multiple discrete Observation Periods which are
+identified by the Observation_Period_Id.
 </td>
 <td style="text-align:left;">
-Assign a unique observation_period_id to each discrete Observation Period for a Person.
+Assign a unique observation_period_id to each discrete Observation
+Period for a Person.
 </td>
 <td style="text-align:left;">
 integer
@@ -1108,7 +1232,8 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The Person ID of the PERSON record for which the Observation Period is recorded.
+The Person ID of the PERSON record for which the Observation Period is
+recorded.
 </td>
 <td style="text-align:left;">
 </td>
@@ -1138,7 +1263,14 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 Use this date to determine the start date of the Observation Period.
 </td>
 <td style="text-align:left;">
-It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">PAYER_PLAN_PERIOD</a>.
+It is often the case that the idea of Observation Periods does not exist
+in source data. In those cases, the observation_period_start_date can be
+inferred as the earliest Event date available for the Person. In
+insurance claim data, the Observation Period can be considered as the
+time period the Person is enrolled with a payer. If a Person switches
+plans but stays with the same payer, and therefore capturing of data
+continues, that change would be captured in <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">PAYER_PLAN_PERIOD</a>.
 </td>
 <td style="text-align:left;">
 date
@@ -1162,10 +1294,15 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 observation_period_end_date
 </td>
 <td style="text-align:left;">
-Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded.
+Use this date to determine the end date of the period for which we can
+assume that all events for a Person are recorded.
 </td>
 <td style="text-align:left;">
-It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer.
+It is often the case that the idea of Observation Periods does not exist
+in source data. In those cases, the observation_period_end_date can be
+inferred as the last Event date available for the Person. In insurance
+claim data, the Observation Period can be considered as the time period
+the Person is enrolled with a payer.
 </td>
 <td style="text-align:left;">
 date
@@ -1189,10 +1326,15 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 period_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.
+This field can be used to determine the provenance of the Observation
+Period as in whether the period was determined from an insurance
+enrollment file, EHR healthcare encounters, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the observation_period_type_concept_id that best represents how the period was determined. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the observation_period_type_concept_id that best represents how
+the period was determined. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1219,25 +1361,100 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 <div id="visit_occurrence" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains Events where Persons engage with the healthcare system for a duration of time. They are often also called “Encounters”. Visits are defined by a configuration of circumstances under which they occur, such as (i) whether the patient comes to a healthcare institution, the other way around, or the interaction is remote, (ii) whether and what kind of trained medical staff is delivering the service during the Visit, and (iii) whether the Visit is transient or for a longer period involving a stay in bed.</p>
+<p>This table contains Events where Persons engage with the healthcare
+system for a duration of time. They are often also called “Encounters”.
+Visits are defined by a configuration of circumstances under which they
+occur, such as (i) whether the patient comes to a healthcare
+institution, the other way around, or the interaction is remote, (ii)
+whether and what kind of trained medical staff is delivering the service
+during the Visit, and (iii) whether the Visit is transient or for a
+longer period involving a stay in bed.</p>
 <p><strong>User Guide</strong></p>
-<p>The configuration defining the Visit are described by Concepts in the Visit Domain, which form a hierarchical structure, but rolling up to generally familiar Visits adopted in most healthcare systems worldwide:</p>
+<p>The configuration defining the Visit are described by Concepts in the
+Visit Domain, which form a hierarchical structure, but rolling up to
+generally familiar Visits adopted in most healthcare systems
+worldwide:</p>
 <ul>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient Visit</a>: Person visiting hospital, at a Care Site, in bed, for duration of more than one day, with physicians and other Providers permanently available to deliver service around the clock</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency Room Visit</a>: Person visiting dedicated healthcare institution for treating emergencies, at a Care Site, within one day, with physicians and Providers permanently available to deliver service around the clock</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER followed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital institution Visit</a>: Person visiting dedicated institution for reasons of poor health, at a Care Site, long-term or permanently, with no physician but possibly other Providers permanently available to deliver service around the clock</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient Visit</a>: Person visiting dedicated ambulatory healthcare institution, at a Care Site, within one day, without bed, with physicians or medical Providers delivering service during Visit</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home Visit</a>: Provider visiting Person, without a Care Site, within one day, delivering service</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/5083">Telehealth Visit</a>: Patient engages with Provider through communication media</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/581458">Pharmacy Visit</a>: Person visiting pharmacy for dispensing of Drug, at a Care Site, within one day</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/32036">Laboratory Visit</a>: Patient visiting dedicated institution, at a Care Site, within one day, for the purpose of a Measurement.</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/581478">Ambulance Visit</a>: Person using transportation service for the purpose of initiating one of the other Visits, without a Care Site, within one day, potentially with Providers accompanying the Visit and delivering service</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/38004193">Case Management Visit</a>: Person interacting with healthcare system, without a Care Site, within a day, with no Providers involved, for administrative purposes</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient
+Visit</a>: Person visiting hospital, at a Care Site, in bed, for
+duration of more than one day, with physicians and other Providers
+permanently available to deliver service around the clock</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency
+Room Visit</a>: Person visiting dedicated healthcare institution for
+treating emergencies, at a Care Site, within one day, with physicians
+and Providers permanently available to deliver service around the
+clock</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency
+Room and Inpatient Visit</a>: Person visiting ER followed by a
+subsequent Inpatient Visit, where Emergency department is part of
+hospital, and transition from the ER to other hospital departments is
+undefined</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital
+institution Visit</a>: Person visiting dedicated institution for reasons
+of poor health, at a Care Site, long-term or permanently, with no
+physician but possibly other Providers permanently available to deliver
+service around the clock</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient
+Visit</a>: Person visiting dedicated ambulatory healthcare institution,
+at a Care Site, within one day, without bed, with physicians or medical
+Providers delivering service during Visit</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home
+Visit</a>: Provider visiting Person, without a Care Site, within one
+day, delivering service</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/5083">Telehealth
+Visit</a>: Patient engages with Provider through communication
+media</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/581458">Pharmacy
+Visit</a>: Person visiting pharmacy for dispensing of Drug, at a Care
+Site, within one day</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/32036">Laboratory
+Visit</a>: Patient visiting dedicated institution, at a Care Site,
+within one day, for the purpose of a Measurement.</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/581478">Ambulance
+Visit</a>: Person using transportation service for the purpose of
+initiating one of the other Visits, without a Care Site, within one day,
+potentially with Providers accompanying the Visit and delivering
+service</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/38004193">Case
+Management Visit</a>: Person interacting with healthcare system, without
+a Care Site, within a day, with no Providers involved, for
+administrative purposes</li>
 </ul>
-<p>The Visit duration, or ‘length of stay’, is defined as VISIT_END_DATE - VISIT_START_DATE. For all Visits this is &lt;1 day, except Inpatient Visits and Non-hospital institution Visits. The CDM also contains the VISIT_DETAIL table where additional information about the Visit is stored, for example, transfers between units during an inpatient Visit.</p>
+<p>The Visit duration, or ‘length of stay’, is defined as VISIT_END_DATE
+- VISIT_START_DATE. For all Visits this is &lt;1 day, except Inpatient
+Visits and Non-hospital institution Visits. The CDM also contains the
+VISIT_DETAIL table where additional information about the Visit is
+stored, for example, transfers between units during an inpatient
+Visit.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Visits can be derived easily if the source data contain coding systems for Place of Service or Procedures, like CPT codes for well visits. In those cases, the codes can be looked up and mapped to a Standard Visit Concept. Otherwise, Visit Concepts have to be identified in the ETL process. This table will contain concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. Visits can be adjacent to each other, i.e. the end date of one can be identical with the start date of the other. As a consequence, more than one-day Visits or their descendants can be recorded for the same day. Multi-day visits must not overlap, i.e. share days other than start and end days. It is often the case that some logic should be written for how to define visits and how to assign Visit_Concept_Id. For example, in US claims outpatient visits that appear to occur within the time period of an inpatient visit can be rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient visits that are within one day of each other may be strung together to create one visit. It will all depend on the source data and how encounter records should be translated to visit occurrences. Providers can be associated with a Visit through the PROVIDER_ID field, or indirectly through PROCEDURE_OCCURRENCE records linked both to the VISIT and PROVIDER tables.</p>
+<p>Visits can be derived easily if the source data contain coding
+systems for Place of Service or Procedures, like CPT codes for well
+visits. In those cases, the codes can be looked up and mapped to a
+Standard Visit Concept. Otherwise, Visit Concepts have to be identified
+in the ETL process. This table will contain concepts in the Visit
+domain. These concepts are arranged in a hierarchical structure to
+facilitate cohort definitions by rolling up to generally familiar Visits
+adopted in most healthcare systems worldwide. Visits can be adjacent to
+each other, i.e. the end date of one can be identical with the start
+date of the other. As a consequence, more than one-day Visits or their
+descendants can be recorded for the same day. Multi-day visits must not
+overlap, i.e. share days other than start and end days. It is often the
+case that some logic should be written for how to define visits and how
+to assign Visit_Concept_Id. For example, in US claims outpatient visits
+that appear to occur within the time period of an inpatient visit can be
+rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient
+visits that are within one day of each other may be strung together to
+create one visit. It will all depend on the source data and how
+encounter records should be translated to visit occurrences. Providers
+can be associated with a Visit through the PROVIDER_ID field, or
+indirectly through PROCEDURE_OCCURRENCE records linked both to the VISIT
+and PROVIDER tables.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -1276,10 +1493,14 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_occurrence_id
 </td>
 <td style="text-align:left;">
-Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit.
+Use this to identify unique interactions between a person and the health
+care system. This identifier links across the other CDM event tables to
+associate events with a visit.
 </td>
 <td style="text-align:left;">
-This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.
+This should be populated by creating a unique identifier for each unique
+interaction between a person and the healthcare system where the person
+receives a medical good or service over a span of time.
 </td>
 <td style="text-align:left;">
 integer
@@ -1329,10 +1550,19 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_concept_id
 </td>
 <td style="text-align:left;">
-This field contains a concept id representing the kind of visit, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.
+This field contains a concept id representing the kind of visit, like
+inpatient or outpatient. All concepts in this field should be standard
+and belong to the Visit domain.
 </td>
 <td style="text-align:left;">
-Populate this field based on the kind of visit that took place for the person. For example this could be “Inpatient Visit”, “Outpatient Visit”, “Ambulatory Visit”, etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Populate this field based on the kind of visit that took place for the
+person. For example this could be “Inpatient Visit”, “Outpatient Visit”,
+“Ambulatory Visit”, etc. This table will contain standard concepts in
+the Visit domain. These concepts are arranged in a hierarchical
+structure to facilitate cohort definitions by rolling up to generally
+familiar Visits adopted in most healthcare systems worldwide. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1358,10 +1588,15 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_start_date
 </td>
 <td style="text-align:left;">
-For inpatient visits, the start date is typically the admission date. For outpatient visits the start date and end date will be the same.
+For inpatient visits, the start date is typically the admission date.
+For outpatient visits the start date and end date will be the same.
 </td>
 <td style="text-align:left;">
-When populating VISIT_START_DATE, you should think about the patient experience to make decisions on how to define visits. In the case of an inpatient visit this should be the date the patient was admitted to the hospital or institution. In all other cases this should be the date of the patient-provider interaction.
+When populating VISIT_START_DATE, you should think about the patient
+experience to make decisions on how to define visits. In the case of an
+inpatient visit this should be the date the patient was admitted to the
+hospital or institution. In all other cases this should be the date of
+the patient-provider interaction.
 </td>
 <td style="text-align:left;">
 date
@@ -1387,7 +1622,8 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the start date of a visit, set it to midnight (00:00:0000).
+If no time is given for the start date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1414,7 +1650,20 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 For inpatient visits the end date is typically the discharge date.
 </td>
 <td style="text-align:left;">
-Visit end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them: - Outpatient Visit: visit_end_datetime = visit_start_datetime - Emergency Room Visit: visit_end_datetime = visit_start_datetime - Inpatient Visit: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. - Non-hospital institution Visits: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs. For Inpatient Visits ongoing at the date of ETL, put date of processing the data into visit_end_datetime and visit_type_concept_id with 32220 “Still patient” to identify the visit as incomplete. - All other Visits: visit_end_datetime = visit_start_datetime. If this is a one-day visit the end date should match the start date.
+Visit end dates are mandatory. If end dates are not provided in the
+source there are three ways in which to derive them: - Outpatient Visit:
+visit_end_datetime = visit_start_datetime - Emergency Room Visit:
+visit_end_datetime = visit_start_datetime - Inpatient Visit: Usually
+there is information about discharge. If not, you should be able to
+derive the end date from the sudden decline of activity or from the
+absence of inpatient procedures/drugs. - Non-hospital institution
+Visits: Particularly for claims data, if end dates are not provided
+assume the visit is for the duration of month that it occurs. For
+Inpatient Visits ongoing at the date of ETL, put date of processing the
+data into visit_end_datetime and visit_type_concept_id with 32220 “Still
+patient” to identify the visit as incomplete. - All other Visits:
+visit_end_datetime = visit_start_datetime. If this is a one-day visit
+the end date should match the start date.
 </td>
 <td style="text-align:left;">
 date
@@ -1440,7 +1689,8 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the end date of a visit, set it to midnight (00:00:0000).
+If no time is given for the end date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1464,10 +1714,14 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_type_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to understand the provenance of the visit record, or where the record comes from.
+Use this field to understand the provenance of the visit record, or
+where the record comes from.
 </td>
 <td style="text-align:left;">
-Populate this field based on the provenance of the visit record, as in whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Populate this field based on the provenance of the visit record, as in
+whether it came from an EHR record or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 Integer
@@ -1493,10 +1747,18 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.
+There will only be one provider per visit record and the ETL document
+should clearly state how they were chosen (attending, admitting, etc.).
+If there are multiple providers associated with a visit in the source,
+this can be reflected in the event tables (CONDITION_OCCURRENCE,
+PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.
 </td>
 <td style="text-align:left;">
-If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#visit_detail">VISIT_DETAIL</a> table.
+If there are multiple providers associated with a visit, you will need
+to choose which one to put here. The additional providers can be stored
+in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#visit_detail">VISIT_DETAIL</a>
+table.
 </td>
 <td style="text-align:left;">
 integer
@@ -1521,7 +1783,8 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-This field provides information about the Care Site where the Visit took place.
+This field provides information about the Care Site where the Visit took
+place.
 </td>
 <td style="text-align:left;">
 There should only be one Care Site associated with a Visit.
@@ -1549,10 +1812,16 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)
+This field houses the verbatim value from the source data representing
+the kind of visit that took place (inpatient, outpatient, emergency,
+etc.)
 </td>
 <td style="text-align:left;">
-If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -&gt; ER-&gt; OP. This should line up with the logic chosen to determine how visits are created.
+If there is information about the kind of visit in the source data that
+value should be stored here. If a visit is an amalgamation of visits
+from the source then use a hierarchy to choose the visit source value,
+such as IP -&gt; ER-&gt; OP. This should line up with the logic chosen
+to determine how visits are created.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1578,7 +1847,9 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the visit source value is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -1603,10 +1874,15 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 admitting_source_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.
+Use this field to determine where the patient was admitted from. This
+concept is part of the visit domain and can indicate if a patient was
+admitted to the hospital from a long-term care facility, for example.
 </td>
 <td style="text-align:left;">
-If available, map the admitted_from_source_value to a standard concept in the visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If available, map the admitted_from_source_value to a standard concept
+in the visit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1634,7 +1910,10 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+admitted from. Typically this applies only to visits that have a length
+of stay, like inpatient visits or long-term care visits.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1658,10 +1937,16 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 discharge_to_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.
+Use this field to determine where the patient was discharged to after a
+visit. This concept is part of the visit domain and can indicate if a
+patient was discharged to home or sent to a long-term care facility, for
+example.
 </td>
 <td style="text-align:left;">
-If available, map the discharge_to_source_value to a standard concept in the visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If available, map the discharge_to_source_value to a standard concept in
+the visit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1689,7 +1974,11 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+discharged to after a visit, as in they went home or were moved to
+long-term care. Typically this applies only to visits that have a length
+of stay of a day or more.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1713,10 +2002,13 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 preceding_visit_occurrence_id
 </td>
 <td style="text-align:left;">
-Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between.
+Use this field to find the visit that occurred for the person prior to
+the given visit. There could be a few days or a few years in between.
 </td>
 <td style="text-align:left;">
-This field can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
+This field can be used to link a visit immediately preceding the current
+visit. Note this is not symmetrical, and there is no such thing as a
+“following_visit_id”.
 </td>
 <td style="text-align:left;">
 integer
@@ -1742,11 +2034,38 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <div id="visit_detail" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <p><strong>Table Description</strong></p>
-<p>The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.</p>
+<p>The VISIT_DETAIL table is an optional table used to represents
+details of each record in the parent VISIT_OCCURRENCE table. A good
+example of this would be the movement between units in a hospital during
+an inpatient stay or claim lines associated with a one insurance claim.
+For every record in the VISIT_OCCURRENCE table there may be 0 or more
+records in the VISIT_DETAIL table with a 1:n relationship where n may be
+0. The VISIT_DETAIL table is structurally very similar to
+VISIT_OCCURRENCE table and belongs to the visit domain.</p>
 <p><strong>User Guide</strong></p>
-<p>The configuration defining the Visit Detail is described by Concepts in the Visit Domain, which form a hierarchical structure. The Visit Detail record will have an associated to the Visit Occurrence record in two ways: <br> 1. The Visit Detail record will have the VISIT_OCCURRENCE_ID it is associated to 2. The VISIT_DETAIL_CONCEPT_ID will be a descendant of the VISIT_CONCEPT_ID for the Visit.</p>
+<p>The configuration defining the Visit Detail is described by Concepts
+in the Visit Domain, which form a hierarchical structure. The Visit
+Detail record will have an associated to the Visit Occurrence record in
+two ways: <br> 1. The Visit Detail record will have the
+VISIT_OCCURRENCE_ID it is associated to 2. The VISIT_DETAIL_CONCEPT_ID
+will be a descendant of the VISIT_CONCEPT_ID for the Visit.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>It is not mandatory that the VISIT_DETAIL table be filled in, but if you find that the logic to create VISIT_OCCURRENCE records includes the roll-up of multiple smaller records to create one picture of a Visit then it is a good idea to use VISIT_DETAIL. In EHR data, for example, a Person may be in the hospital but instead of one over-arching Visit their encounters are recorded as times they interacted with a health care provider. A Person in the hospital interacts with multiple providers multiple times a day so the encounters must be strung together using some heuristic (defined by the ETL) to identify the entire Visit. In this case the encounters would be considered Visit Details and the entire Visit would be the Visit Occurrence. In this example it is also possible to use the Vocabulary to distinguish Visit Details from a Visit Occurrence by setting the VISIT_CONCEPT_ID to <a href="https://athena.ohdsi.org/search-terms/terms/9201">9201</a> and the VISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicate where the patient was in the hospital at the time of care.</p>
+<p>It is not mandatory that the VISIT_DETAIL table be filled in, but if
+you find that the logic to create VISIT_OCCURRENCE records includes the
+roll-up of multiple smaller records to create one picture of a Visit
+then it is a good idea to use VISIT_DETAIL. In EHR data, for example, a
+Person may be in the hospital but instead of one over-arching Visit
+their encounters are recorded as times they interacted with a health
+care provider. A Person in the hospital interacts with multiple
+providers multiple times a day so the encounters must be strung together
+using some heuristic (defined by the ETL) to identify the entire Visit.
+In this case the encounters would be considered Visit Details and the
+entire Visit would be the Visit Occurrence. In this example it is also
+possible to use the Vocabulary to distinguish Visit Details from a Visit
+Occurrence by setting the VISIT_CONCEPT_ID to <a
+href="https://athena.ohdsi.org/search-terms/terms/9201">9201</a> and the
+VISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicate
+where the patient was in the hospital at the time of care.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -1785,10 +2104,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail.
+Use this to identify unique interactions between a person and the health
+care system. This identifier links across the other CDM event tables to
+associate events with a visit detail.
 </td>
 <td style="text-align:left;">
-This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.
+This should be populated by creating a unique identifier for each unique
+interaction between a person and the healthcare system where the person
+receives a medical good or service over a span of time.
 </td>
 <td style="text-align:left;">
 integer
@@ -1838,10 +2161,19 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_concept_id
 </td>
 <td style="text-align:left;">
-This field contains a concept id representing the kind of visit detail, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.
+This field contains a concept id representing the kind of visit detail,
+like inpatient or outpatient. All concepts in this field should be
+standard and belong to the Visit domain.
 </td>
 <td style="text-align:left;">
-Populate this field based on the kind of visit that took place for the person. For example this could be “Inpatient Visit”, “Outpatient Visit”, “Ambulatory Visit”, etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Populate this field based on the kind of visit that took place for the
+person. For example this could be “Inpatient Visit”, “Outpatient Visit”,
+“Ambulatory Visit”, etc. This table will contain standard concepts in
+the Visit domain. These concepts are arranged in a hierarchical
+structure to facilitate cohort definitions by rolling up to generally
+familiar Visits adopted in most healthcare systems worldwide. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1867,10 +2199,13 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_start_date
 </td>
 <td style="text-align:left;">
-This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with.
+This is the date of the start of the encounter. This may or may not be
+equal to the date of the Visit the Visit Detail is associated with.
 </td>
 <td style="text-align:left;">
-When populating VISIT_DETAIL_START_DATE, you should think about the patient experience to make decisions on how to define visits. Most likely this should be the date of the patient-provider interaction.
+When populating VISIT_DETAIL_START_DATE, you should think about the
+patient experience to make decisions on how to define visits. Most
+likely this should be the date of the patient-provider interaction.
 </td>
 <td style="text-align:left;">
 date
@@ -1896,7 +2231,8 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the start date of a visit, set it to midnight (00:00:0000).
+If no time is given for the start date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1923,7 +2259,21 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 This the end date of the patient-provider interaction.
 </td>
 <td style="text-align:left;">
-Visit Detail end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them:<br> - Outpatient Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Emergency Room Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Inpatient Visit Detail: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. - Non-hospital institution Visit Details: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs.<br> For Inpatient Visit Details ongoing at the date of ETL, put date of processing the data into visit_detai_end_datetime and visit_detail_type_concept_id with 32220 “Still patient” to identify the visit as incomplete. All other Visits Details: visit_detail_end_datetime = visit_detail_start_datetime.
+Visit Detail end dates are mandatory. If end dates are not provided in
+the source there are three ways in which to derive them:<br> -
+Outpatient Visit Detail: visit_detail_end_datetime =
+visit_detail_start_datetime - Emergency Room Visit Detail:
+visit_detail_end_datetime = visit_detail_start_datetime - Inpatient
+Visit Detail: Usually there is information about discharge. If not, you
+should be able to derive the end date from the sudden decline of
+activity or from the absence of inpatient procedures/drugs. -
+Non-hospital institution Visit Details: Particularly for claims data, if
+end dates are not provided assume the visit is for the duration of month
+that it occurs.<br> For Inpatient Visit Details ongoing at the date of
+ETL, put date of processing the data into visit_detai_end_datetime and
+visit_detail_type_concept_id with 32220 “Still patient” to identify the
+visit as incomplete. All other Visits Details: visit_detail_end_datetime
+= visit_detail_start_datetime.
 </td>
 <td style="text-align:left;">
 date
@@ -1949,7 +2299,8 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the end date of a visit, set it to midnight (00:00:0000).
+If no time is given for the end date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1973,10 +2324,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_type_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to understand the provenance of the visit detail record, or where the record comes from.
+Use this field to understand the provenance of the visit detail record,
+or where the record comes from.
 </td>
 <td style="text-align:left;">
-Populate this field based on the provenance of the visit detail record, as in whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Populate this field based on the provenance of the visit detail record,
+as in whether it came from an EHR record or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2002,10 +2357,16 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-There will only be one provider per <strong>visit</strong> record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record.
+There will only be one provider per <strong>visit</strong> record and
+the ETL document should clearly state how they were chosen (attending,
+admitting, etc.). This is a typical reason for leveraging the
+VISIT_DETAIL table as even though each VISIT_DETAIL record can only have
+one provider, there is no limit to the number of VISIT_DETAIL records
+that can be associated to a VISIT_OCCURRENCE record.
 </td>
 <td style="text-align:left;">
-The additional providers associated to a Visit can be stored in this table where each VISIT_DETAIL record represents a different provider.
+The additional providers associated to a Visit can be stored in this
+table where each VISIT_DETAIL record represents a different provider.
 </td>
 <td style="text-align:left;">
 integer
@@ -2030,7 +2391,8 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-This field provides information about the Care Site where the Visit Detail took place.
+This field provides information about the Care Site where the Visit
+Detail took place.
 </td>
 <td style="text-align:left;">
 There should only be one Care Site associated with a Visit Detail.
@@ -2058,10 +2420,16 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)
+This field houses the verbatim value from the source data representing
+the kind of visit detail that took place (inpatient, outpatient,
+emergency, etc.)
 </td>
 <td style="text-align:left;">
-If there is information about the kind of visit detail in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the VISIT_DETAIL_SOURCE_VALUE, such as IP -&gt; ER-&gt; OP. This should line up with the logic chosen to determine how visits are created.
+If there is information about the kind of visit detail in the source
+data that value should be stored here. If a visit is an amalgamation of
+visits from the source then use a hierarchy to choose the
+VISIT_DETAIL_SOURCE_VALUE, such as IP -&gt; ER-&gt; OP. This should line
+up with the logic chosen to determine how visits are created.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2087,7 +2455,9 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an
+OMOP supported vocabulary put the concept id representing the source
+value here.
 </td>
 <td style="text-align:left;">
 Integer
@@ -2114,7 +2484,10 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+admitted from. Typically this applies only to visits that have a length
+of stay, like inpatient visits or long-term care visits.
 </td>
 <td style="text-align:left;">
 Varchar(50)
@@ -2138,10 +2511,15 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 admitting_source_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.
+Use this field to determine where the patient was admitted from. This
+concept is part of the visit domain and can indicate if a patient was
+admitted to the hospital from a long-term care facility, for example.
 </td>
 <td style="text-align:left;">
-If available, map the admitted_from_source_value to a standard concept in the visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If available, map the admitted_from_source_value to a standard concept
+in the visit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 Integer
@@ -2169,7 +2547,11 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+discharged to after a visit, as in they went home or were moved to
+long-term care. Typically this applies only to visits that have a length
+of stay of a day or more.
 </td>
 <td style="text-align:left;">
 Varchar(50)
@@ -2193,10 +2575,16 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 discharge_to_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was discharged to after a visit detail record. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.
+Use this field to determine where the patient was discharged to after a
+visit detail record. This concept is part of the visit domain and can
+indicate if a patient was discharged to home or sent to a long-term care
+facility, for example.
 </td>
 <td style="text-align:left;">
-If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in
+the Visit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2222,10 +2610,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 preceding_visit_detail_id
 </td>
 <td style="text-align:left;">
-Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.
+Use this field to find the visit detail that occurred for the person
+prior to the given visit detail record. There could be a few days or a
+few years in between.
 </td>
 <td style="text-align:left;">
-The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
+The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately
+preceding the current Visit Detail. Note this is not symmetrical, and
+there is no such thing as a “following_visit_id”.
 </td>
 <td style="text-align:left;">
 integer
@@ -2250,10 +2642,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_parent_id
 </td>
 <td style="text-align:left;">
-Use this field to find the visit detail that subsumes the given visit detail record. This is used in the case that a visit detail record needs to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.
+Use this field to find the visit detail that subsumes the given visit
+detail record. This is used in the case that a visit detail record needs
+to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.
 </td>
 <td style="text-align:left;">
-If there are multiple nested levels to how Visits are represented in the source, the VISIT_DETAIL_PARENT_ID can be used to record this relationship.
+If there are multiple nested levels to how Visits are represented in the
+source, the VISIT_DETAIL_PARENT_ID can be used to record this
+relationship.
 </td>
 <td style="text-align:left;">
 integer
@@ -2304,14 +2700,47 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 </tbody>
 </table>
 </div>
-<div id="condition_occurrence" class="section level3 tabset tabset-pills">
+<div id="condition_occurrence"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.</p>
+<p>This table contains records of Events of a Person suggesting the
+presence of a disease or medical condition stated as a diagnosis, a
+sign, or a symptom, which is either observed by a Provider or reported
+by the patient.</p>
 <p><strong>User Guide</strong></p>
-<p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype definitions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p>
+<p>Conditions are defined by Concepts from the Condition domain, which
+form a complex hierarchy. As a result, the same Person with the same
+disease may have multiple Condition records, which belong to the same
+hierarchical family. Most Condition records are mapped from diagnostic
+codes, but recorded signs, symptoms and summary descriptions also
+contribute to this table. Rule out diagnoses should not be recorded in
+this table, but in reality their negating nature is not always captured
+in the source data, and other precautions must be taken when when
+identifying Persons who should suffer from the recorded Condition.
+Record all conditions as they exist in the source data. Any decisions
+about diagnosis/phenotype definitions would be done through cohort
+specifications. These cohorts can be housed in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a>
+table. Conditions span a time interval from start to end, but are
+typically recorded as single snapshot records with no end date. The
+reason is twofold: (i) At the time of the recording the duration is not
+known and later not recorded, and (ii) the Persons typically cease
+interacting with the healthcare system when they feel better, which
+leads to incomplete capture of resolved Conditions. The <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a>
+table addresses this issue. Family history and past diagnoses (‘history
+of’) are not recorded in this table. Instead, they are listed in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a>
+table. Codes written in the process of establishing the diagnosis, such
+as ‘question of’ of and ‘rule out’, should not represented here.
+Instead, they should be recorded in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a>
+table, if they are used for analyses. However, this information is not
+always available.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.</p>
+<p>Source codes and source text fields mapped to Standard Concepts of
+the Condition Domain have to be recorded here.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -2350,10 +2779,16 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_occurrence_id
 </td>
 <td style="text-align:left;">
-The unique key given to a condition record for a person. Refer to the ETL for how duplicate conditions during the same visit were handled.
+The unique key given to a condition record for a person. Refer to the
+ETL for how duplicate conditions during the same visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a condition present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same condition within the same visit. It is valid to keep these duplicates and assign them individual, unique, CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be handled.
+Each instance of a condition present in the source data should be
+assigned this unique key. In some cases, a person can have multiple
+records of the same condition within the same visit. It is valid to keep
+these duplicates and assign them individual, unique,
+CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be
+handled.
 </td>
 <td style="text-align:left;">
 integer
@@ -2404,10 +2839,16 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_concept_id
 </td>
 <td style="text-align:left;">
-The CONDITION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a condition
+The CONDITION_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies. This is the standard
+concept mapped from the source value which represents a condition
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records whose source values map to concepts with a domain of “Condition” should go in this table. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Condition&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records
+whose source values map to concepts with a domain of “Condition” should
+go in this table. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Condition&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2436,7 +2877,10 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 Use this date to determine the start date of the condition
 </td>
 <td style="text-align:left;">
-Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE.
+Most often data sources do not have the idea of a start date for a
+condition. Rather, if a source only has one date associated with a
+condition record it is acceptable to use that date for both the
+CONDITION_START_DATE and the CONDITION_END_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -2462,7 +2906,8 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+If a source does not specify datetime the convention is to set the time
+to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -2489,7 +2934,10 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 Use this date to determine the end date of the condition
 </td>
 <td style="text-align:left;">
-Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE.
+Most often data sources do not have the idea of a start date for a
+condition. Rather, if a source only has one date associated with a
+condition record it is acceptable to use that date for both the
+CONDITION_START_DATE and the CONDITION_END_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -2515,7 +2963,8 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+If a source does not specify datetime the convention is to set the time
+to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -2539,10 +2988,15 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Condition
+record, as in whether the condition was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance of the record. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance
+of the record. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2568,10 +3022,18 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_status_concept_id
 </td>
 <td style="text-align:left;">
-This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others.
+This concept represents the point during the visit the diagnosis was
+given (admitting diagnosis, final diagnosis), whether the diagnosis was
+determined due to laboratory findings, if the diagnosis was
+exclusionary, or if it was a preliminary diagnosis, among others.
 </td>
 <td style="text-align:left;">
-Choose the Concept in the Condition Status domain that best represents the point during the visit when the diagnosis was given. These can include admitting diagnosis, principal diagnosis, and secondary diagnosis. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the Concept in the Condition Status domain that best represents
+the point during the visit when the diagnosis was given. These can
+include admitting diagnosis, principal diagnosis, and secondary
+diagnosis. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2597,10 +3059,13 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 stop_reason
 </td>
 <td style="text-align:left;">
-The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring.
+The Stop Reason indicates why a Condition is no longer valid with
+respect to the purpose within the source data. Note that a Stop Reason
+does not necessarily imply that the condition is no longer occurring.
 </td>
 <td style="text-align:left;">
-This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist.
+This information is often not populated in source data and it is a valid
+etl choice to leave it blank if the information does not exist.
 </td>
 <td style="text-align:left;">
 varchar(20)
@@ -2624,10 +3089,14 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with condition record, e.g. the provider who made the diagnosis or the provider who recorded the symptom.
+The provider associated with condition record, e.g. the provider who
+made the diagnosis or the provider who recorded the symptom.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record, for
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -2655,7 +3124,13 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 The visit during which the condition occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If a CONDITION_START_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE record.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If a CONDITION_START_DATE occurs within the
+start and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE
+record.
 </td>
 <td style="text-align:left;">
 integer
@@ -2680,7 +3155,11 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the condition occurred. For example, if the person was in the ICU at the time of the diagnosis the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the condition occurred. For
+example, if the person was in the ICU at the time of the diagnosis the
+VISIT_OCCURRENCE record would reflect the overall hospital stay and the
+VISIT_DETAIL record would reflect the ICU stay during the hospital
+visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -2708,10 +3187,13 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the condition that occurred. For example, this could be an ICD10 or Read code.
+This field houses the verbatim value from the source data representing
+the condition that occurred. For example, this could be an ICD10 or Read
+code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2735,10 +3217,19 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the condition source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Condition necessary for a given analytic use case. Consider using CONDITION_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the condition source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Condition
+necessary for a given analytic use case. Consider using
+CONDITION_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -2763,10 +3254,15 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_status_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the condition status.
+This field houses the verbatim value from the source data representing
+the condition status.
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating when and how a diagnosis was given to a patient. This source value is mapped to a standard concept which is stored in the CONDITION_STATUS_CONCEPT_ID field.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating when and how a
+diagnosis was given to a patient. This source value is mapped to a
+standard concept which is stored in the CONDITION_STATUS_CONCEPT_ID
+field.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2791,11 +3287,34 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <div id="drug_exposure" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table captures records about the exposure to a Drug ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain biochemical effect on the metabolism. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.</p>
+<p>This table captures records about the exposure to a Drug ingested or
+otherwise introduced into the body. A Drug is a biochemical substance
+formulated in such a way that when administered to a Person it will
+exert a certain biochemical effect on the metabolism. Drugs include
+prescription and over-the-counter medicines, vaccines, and
+large-molecule biologic therapies. Radiological devices ingested or
+applied locally do not count as Drugs.</p>
 <p><strong>User Guide</strong></p>
-<p>The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.</p>
+<p>The purpose of records in this table is to indicate an exposure to a
+certain drug as best as possible. In this context a drug is defined as
+an active ingredient. Drug Exposures are defined by Concepts from the
+Drug domain, which form a complex hierarchy. As a result, one
+DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is
+a combination product. Records in this table represent prescriptions
+written, prescriptions dispensed, and drugs administered by a provider
+to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter
+on these types. This table includes additional information about the
+drug products, the quantity given, and route of administration.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs administered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p>
+<p>Information about quantity and dose is provided in a variety of
+different ways and it is important for the ETL to provide as much
+information as possible from the data. Depending on the provenance of
+the data fields may be captured differently i.e. quantity for drugs
+administered may have a separate meaning from quantity for prescriptions
+dispensed. If a patient has multiple records on the same day for the
+same drug or procedures the ETL should not de-dupe them unless there is
+probable reason to believe the item is a true data duplicate. Take note
+on how to handle refills for prescriptions written.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -2834,10 +3353,17 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_exposure_id
 </td>
 <td style="text-align:left;">
-The unique key given to records of drug dispensings or administrations for a person. Refer to the ETL for how duplicate drugs during the same visit were handled.
+The unique key given to records of drug dispensings or administrations
+for a person. Refer to the ETL for how duplicate drugs during the same
+visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a drug dispensing or administration present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same drug within the same visit. It is valid to keep these duplicates and assign them individual, unique, DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be handled.
+Each instance of a drug dispensing or administration present in the
+source data should be assigned this unique key. In some cases, a person
+can have multiple records of the same drug within the same visit. It is
+valid to keep these duplicates and assign them individual, unique,
+DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be
+handled.
 </td>
 <td style="text-align:left;">
 integer
@@ -2861,7 +3387,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the PERSON for whom the drug dispensing or administration is recorded. This may be a system generated code.
+The PERSON_ID of the PERSON for whom the drug dispensing or
+administration is recorded. This may be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -2888,10 +3415,35 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_concept_id
 </td>
 <td style="text-align:left;">
-The DRUG_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a drug product or molecule otherwise introduced to the body. The drug concepts can have a varying degree of information about drug strength and dose. This information is relevant in the context of quantity and administration information in the subsequent fields plus strength information from the DRUG_STRENGTH table, provided as part of the standard vocabulary download.
+The DRUG_CONCEPT_ID field is recommended for primary use in analyses,
+and must be used for network studies. This is the standard concept
+mapped from the source concept id which represents a drug product or
+molecule otherwise introduced to the body. The drug concepts can have a
+varying degree of information about drug strength and dose. This
+information is relevant in the context of quantity and administration
+information in the subsequent fields plus strength information from the
+DRUG_STRENGTH table, provided as part of the standard vocabulary
+download.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should be derived either from mapping from the source concept id or by picking the drug concept representing the most amount of detail you have. Records whose source values map to standard concepts with a domain of Drug should go in this table. When the Drug Source Value of the code cannot be translated into Standard Drug Concept IDs, a Drug exposure entry is stored with only the corresponding SOURCE_CONCEPT_ID and DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the most detailed content of information is preferred during the mapping process. These are indicated in the CONCEPT_CLASS_ID field of the Concept and are recorded in the following order of precedence: ‘Branded Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical Drug Form’, and only if no other information is available ‘Ingredient’. Note: If only the drug class is known, the DRUG_CONCEPT_ID field should contain 0. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Drug&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should
+be derived either from mapping from the source concept id or by picking
+the drug concept representing the most amount of detail you have.
+Records whose source values map to standard concepts with a domain of
+Drug should go in this table. When the Drug Source Value of the code
+cannot be translated into Standard Drug Concept IDs, a Drug exposure
+entry is stored with only the corresponding SOURCE_CONCEPT_ID and
+DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the
+most detailed content of information is preferred during the mapping
+process. These are indicated in the CONCEPT_CLASS_ID field of the
+Concept and are recorded in the following order of precedence: ‘Branded
+Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug
+Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical
+Drug Form’, and only if no other information is available ‘Ingredient’.
+Note: If only the drug class is known, the DRUG_CONCEPT_ID field should
+contain 0. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Drug&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2920,7 +3472,10 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 Use this date to determine the start date of the drug record.
 </td>
 <td style="text-align:left;">
-Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration was recorded. It is a valid ETL choice to use the date the drug was ordered as the DRUG_EXPOSURE_START_DATE.
+Valid entries include a start date of a prescription, the date a
+prescription was filled, or the date on which a Drug administration was
+recorded. It is a valid ETL choice to use the date the drug was ordered
+as the DRUG_EXPOSURE_START_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -2946,7 +3501,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -2970,10 +3526,27 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_exposure_end_date
 </td>
 <td style="text-align:left;">
-The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.
+The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for
+the patient.
 </td>
 <td style="text-align:left;">
-If this information is not explicitly available in the data, infer the end date using the following methods:<br><br> 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL) 200*5/20 = 50 days. <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples by dose form</a>
+If this information is not explicitly available in the data, infer the
+end date using the following methods:<br><br> 1. Start first with
+duration or days supply using the calculation drug start date + days
+supply -1 day. 2. Use quantity divided by daily dose that you may obtain
+from the sig or a source field (or assumed daily dose of 1) for solid,
+indivisibile, drug products. If quantity represents ingredient amount,
+quantity divided by daily dose * concentration (from drug_strength) drug
+concept id tells you the dose form. 3. If it is an administration
+record, set drug end date equal to drug start date. If the record is a
+written prescription then set end date to start date + 29. If the record
+is a mail-order prescription set end date to start date + 89. The end
+date must be equal to or greater than the start date. Ibuprofen 20mg/mL
+oral solution concept tells us this is oral solution. Calculate duration
+as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL)
+200*5/20 = 50 days. <a
+href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples
+by dose form</a>
 </td>
 <td style="text-align:left;">
 date
@@ -2999,7 +3572,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -3023,10 +3597,12 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 verbatim_end_date
 </td>
 <td style="text-align:left;">
-This is the end date of the drug exposure as it appears in the source data, if it is given
+This is the end date of the drug exposure as it appears in the source
+data, if it is given
 </td>
 <td style="text-align:left;">
-Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable.
+Put the end date or discontinuation date as it appears from the source
+data or leave blank if unavailable.
 </td>
 <td style="text-align:left;">
 date
@@ -3050,10 +3626,16 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_type_concept_id
 </td>
 <td style="text-align:left;">
-You can use the TYPE_CONCEPT_ID to delineate between prescriptions written vs. prescriptions dispensed vs. medication history vs. patient-reported exposure, etc.
+You can use the TYPE_CONCEPT_ID to delineate between prescriptions
+written vs. prescriptions dispensed vs. medication history
+vs. patient-reported exposure, etc.
 </td>
 <td style="text-align:left;">
-Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the drug_type_concept_id that best represents the provenance of
+the record, for example whether it came from a record of a prescription
+written or physician administered drug. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3079,10 +3661,13 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 stop_reason
 </td>
 <td style="text-align:left;">
-The reason a person stopped a medication as it is represented in the source. Reasons include regimen completed, changed, removed, etc. This field will be retired in v6.0.
+The reason a person stopped a medication as it is represented in the
+source. Reasons include regimen completed, changed, removed, etc. This
+field will be retired in v6.0.
 </td>
 <td style="text-align:left;">
-This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist.
+This information is often not populated in source data and it is a valid
+etl choice to leave it blank if the information does not exist.
 </td>
 <td style="text-align:left;">
 varchar(20)
@@ -3106,7 +3691,9 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 refills
 </td>
 <td style="text-align:left;">
-This is only filled in when the record is coming from a prescription written this field is meant to represent intended refills at time of the prescription.
+This is only filled in when the record is coming from a prescription
+written this field is meant to represent intended refills at time of the
+prescription.
 </td>
 <td style="text-align:left;">
 </td>
@@ -3134,7 +3721,22 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-To find the dose form of a drug the RELATIONSHIP table can be used where the relationship_id is ‘Has dose form’. If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the DRUG_STRENGTH table the quantity should be converted to the correct unit given in DRUG_STRENGTH. For clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160. Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similar to clinical drugs. Please see <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to calculate drug dose</a> for more information.
+To find the dose form of a drug the RELATIONSHIP table can be used where
+the relationship_id is ‘Has dose form’. If liquid, quantity stands for
+the total amount dispensed or ordered of ingredient in the units given
+by the drug_strength table. If the unit from the source data does not
+align with the unit in the DRUG_STRENGTH table the quantity should be
+converted to the correct unit given in DRUG_STRENGTH. For clinical drugs
+with fixed dose forms (tablets etc.) the quantity is the number of
+units/tablets/capsules prescribed or dispensed (can be partial, but then
+only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms
+(injections) the quantity is the amount of ingredient the patient got.
+For example, if the injection is 2mg/mL but the patient got 80mL then
+quantity is reported as 160. Quantified clinical drugs with divisible
+dose forms (prefilled syringes), the quantity is the amount of
+ingredient similar to clinical drugs. Please see <a
+href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to
+calculate drug dose</a> for more information.
 </td>
 <td style="text-align:left;">
 float
@@ -3160,7 +3762,10 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Days supply of the drug. This should be the verbatim days_supply as given on the prescription. If the drug is physician administered use duration end date if given or set to 1 as default if duration is not available.
+Days supply of the drug. This should be the verbatim days_supply as
+given on the prescription. If the drug is physician administered use
+duration end date if given or set to 1 as default if duration is not
+available.
 </td>
 <td style="text-align:left;">
 integer
@@ -3184,10 +3789,12 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 sig
 </td>
 <td style="text-align:left;">
-This is the verbatim instruction for the drug as written by the provider.
+This is the verbatim instruction for the drug as written by the
+provider.
 </td>
 <td style="text-align:left;">
-Put the written out instructions for the drug as it is verbatim in the source, if available.
+Put the written out instructions for the drug as it is verbatim in the
+source, if available.
 </td>
 <td style="text-align:left;">
 varchar(MAX)
@@ -3213,7 +3820,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route domain.
+The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route
+domain.
 </td>
 <td style="text-align:left;">
 integer
@@ -3264,10 +3872,14 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The Provider associated with drug record, e.g. the provider who wrote the prescription or the provider who administered the drug.
+The Provider associated with drug record, e.g. the provider who wrote
+the prescription or the provider who administered the drug.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the ordering vs administering physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record, for
+example the ordering vs administering physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -3292,10 +3904,12 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 visit_occurrence_id
 </td>
 <td style="text-align:left;">
-The Visit during which the drug was prescribed, administered or dispensed.
+The Visit during which the drug was prescribed, administered or
+dispensed.
 </td>
 <td style="text-align:left;">
-To populate this field drug exposures must be explicitly initiated in the visit.
+To populate this field drug exposures must be explicitly initiated in
+the visit.
 </td>
 <td style="text-align:left;">
 integer
@@ -3320,7 +3934,11 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the drug exposure occurred. For example, if the person was in the ICU at the time of the drug administration the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the drug exposure occurred. For
+example, if the person was in the ICU at the time of the drug
+administration the VISIT_OCCURRENCE record would reflect the overall
+hospital stay and the VISIT_DETAIL record would reflect the ICU stay
+during the hospital visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -3348,10 +3966,13 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the drug exposure that occurred. For example, this could be an NDC or Gemscript code.
+This field houses the verbatim value from the source data representing
+the drug exposure that occurred. For example, this could be an NDC or
+Gemscript code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Drug Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Drug Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3375,10 +3996,19 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the drug source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Drug necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the drug source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Drug
+necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID
+instead to enable standardized analytics that can be consistent across
+the network.
 </td>
 <td style="text-align:left;">
-If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -3403,10 +4033,14 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 route_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the drug route.
+This field houses the verbatim value from the source data representing
+the drug route.
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating when and how a drug was given to a patient. This source value is mapped to a standard concept which is stored in the ROUTE_CONCEPT_ID field.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating when and how a drug
+was given to a patient. This source value is mapped to a standard
+concept which is stored in the ROUTE_CONCEPT_ID field.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3430,10 +4064,14 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 dose_unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the dose unit of the drug given.
+This field houses the verbatim value from the source data representing
+the dose unit of the drug given.
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating the unit of dosage of drug given to the patient. This is an older column and will be deprecated in an upcoming version.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating the unit of dosage
+of drug given to the patient. This is an older column and will be
+deprecated in an upcoming version.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3455,14 +4093,34 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 </tbody>
 </table>
 </div>
-<div id="procedure_occurrence" class="section level3 tabset tabset-pills">
+<div id="procedure_occurrence"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.</p>
+<p>This table contains records of activities or processes ordered by, or
+carried out by, a healthcare provider on the patient with a diagnostic
+or therapeutic purpose.</p>
 <p><strong>User Guide</strong></p>
-<p>Lab tests are not a procedure, if something is observed with an expected resulting amount and unit then it should be a measurement. Phlebotomy is a procedure but so trivial that it tends to be rarely captured. It can be assumed that there is a phlebotomy procedure associated with many lab tests, therefore it is unnecessary to add them as separate procedures. If the user finds the same procedure over concurrent days, it is assumed those records are part of a procedure lasting more than a day. This logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM.</p>
+<p>Lab tests are not a procedure, if something is observed with an
+expected resulting amount and unit then it should be a measurement.
+Phlebotomy is a procedure but so trivial that it tends to be rarely
+captured. It can be assumed that there is a phlebotomy procedure
+associated with many lab tests, therefore it is unnecessary to add them
+as separate procedures. If the user finds the same procedure over
+concurrent days, it is assumed those records are part of a procedure
+lasting more than a day. This logic is in lieu of the
+procedure_end_date, which will be added in a future version of the
+CDM.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>If a procedure lasts more than 24 hours, then it should be recorded as a separate record for each day the procedure occurred, this logic is in lieu of the PROCEDURE_END_DATE, which will be added in a future version of the CDM. When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are: - Same Procedure - Same PROCEDURE_DATETIME - Same Visit Occurrence or Visit Detail - Same Provider - Same Modifier for Procedures. Source codes and source text fields mapped to Standard Concepts of the Procedure Domain have to be recorded here.</p>
+<p>If a procedure lasts more than 24 hours, then it should be recorded
+as a separate record for each day the procedure occurred, this logic is
+in lieu of the PROCEDURE_END_DATE, which will be added in a future
+version of the CDM. When dealing with duplicate records, the ETL must
+determine whether to sum them up into one record or keep them separate.
+Things to consider are: - Same Procedure - Same PROCEDURE_DATETIME -
+Same Visit Occurrence or Visit Detail - Same Provider - Same Modifier
+for Procedures. Source codes and source text fields mapped to Standard
+Concepts of the Procedure Domain have to be recorded here.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -3501,10 +4159,16 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_occurrence_id
 </td>
 <td style="text-align:left;">
-The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled.
+The unique key given to a procedure record for a person. Refer to the
+ETL for how duplicate procedures during the same visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled.
+Each instance of a procedure occurrence in the source data should be
+assigned this unique key. In some cases, a person can have multiple
+records of the same procedure within the same visit. It is valid to keep
+these duplicates and assign them individual, unique,
+PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be
+handled.
 </td>
 <td style="text-align:left;">
 integer
@@ -3528,7 +4192,8 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the PERSON for whom the procedure is recorded. This may be a system generated code.
+The PERSON_ID of the PERSON for whom the procedure is recorded. This may
+be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -3555,10 +4220,16 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_concept_id
 </td>
 <td style="text-align:left;">
-The PROCEDURE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a procedure
+The PROCEDURE_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies. This is the standard
+concept mapped from the source value which represents a procedure
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records whose source values map to standard concepts with a domain of “Procedure” should go in this table. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Procedure&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records
+whose source values map to standard concepts with a domain of
+“Procedure” should go in this table. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Procedure&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3587,7 +4258,10 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 Use this date to determine the date the procedure occurred.
 </td>
 <td style="text-align:left;">
-If a procedure lasts more than a day, then it should be recorded as a separate record for each day the procedure occurred, this logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM.
+If a procedure lasts more than a day, then it should be recorded as a
+separate record for each day the procedure occurred, this logic is in
+lieu of the procedure_end_date, which will be added in a future version
+of the CDM.
 </td>
 <td style="text-align:left;">
 date
@@ -3613,7 +4287,8 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -3637,10 +4312,17 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Procedure record, as in whether the procedure was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Procedure
+record, as in whether the procedure was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. If a procedure is recorded as an EHR encounter, the PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance
+of the record, for example whether it came from an EHR record or billing
+claim. If a procedure is recorded as an EHR encounter, the
+PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3666,10 +4348,17 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 modifier_concept_id
 </td>
 <td style="text-align:left;">
-The modifiers are intended to give additional information about the procedure but as of now the vocabulary is under review.
+The modifiers are intended to give additional information about the
+procedure but as of now the vocabulary is under review.
 </td>
 <td style="text-align:left;">
-It is up to the ETL to choose how to map modifiers if they exist in source data. These concepts are typically distinguished by ‘Modifier’ concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’ vocabulary). If there is more than one modifier on a record, one should be chosen that pertains to the procedure rather than provider. <a href="https://athena.ohdsi.org/search-terms/terms?conceptClass=CPT4+Modifier&amp;conceptClass=HCPCS+Modifier&amp;vocabulary=CPT4&amp;vocabulary=HCPCS&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+It is up to the ETL to choose how to map modifiers if they exist in
+source data. These concepts are typically distinguished by ‘Modifier’
+concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’
+vocabulary). If there is more than one modifier on a record, one should
+be chosen that pertains to the procedure rather than provider. <a
+href="https://athena.ohdsi.org/search-terms/terms?conceptClass=CPT4+Modifier&amp;conceptClass=HCPCS+Modifier&amp;vocabulary=CPT4&amp;vocabulary=HCPCS&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3697,7 +4386,9 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 If the quantity value is omitted, a single procedure is assumed.
 </td>
 <td style="text-align:left;">
-If a Procedure has a quantity of ‘0’ in the source, this should default to ‘1’ in the ETL. If there is a record in the source it can be assumed the exposure occurred at least once
+If a Procedure has a quantity of ‘0’ in the source, this should default
+to ‘1’ in the ETL. If there is a record in the source it can be assumed
+the exposure occurred at least once
 </td>
 <td style="text-align:left;">
 integer
@@ -3721,10 +4412,14 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with the procedure record, e.g. the provider who performed the Procedure.
+The provider associated with the procedure record, e.g. the provider who
+performed the Procedure.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record, for
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -3752,7 +4447,13 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 The visit during which the procedure occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If a PROCEDURE_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE record.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If a PROCEDURE_DATE occurs within the start
+and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE
+record.
 </td>
 <td style="text-align:left;">
 integer
@@ -3777,7 +4478,11 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the Procedure occurred. For example, if the Person was in the ICU at the time of the Procedure the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the Procedure occurred. For
+example, if the Person was in the ICU at the time of the Procedure the
+VISIT_OCCURRENCE record would reflect the overall hospital stay and the
+VISIT_DETAIL record would reflect the ICU stay during the hospital
+visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -3805,10 +4510,13 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the procedure that occurred. For example, this could be an CPT4 or OPCS4 code.
+This field houses the verbatim value from the source data representing
+the procedure that occurred. For example, this could be an CPT4 or OPCS4
+code.
 </td>
 <td style="text-align:left;">
-Use this value to look up the source concept id and then map the source concept id to a standard concept id.
+Use this value to look up the source concept id and then map the source
+concept id to a standard concept id.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3832,10 +4540,19 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the procedure source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Procedure necessary for a given analytic use case. Consider using PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the procedure source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Procedure
+necessary for a given analytic use case. Consider using
+PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -3887,11 +4604,21 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 <div id="device_exposure" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <p><strong>Table Description</strong></p>
-<p>The Device domain captures information about a person’s exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).</p>
+<p>The Device domain captures information about a person’s exposure to a
+foreign physical object or instrument which is used for diagnostic or
+therapeutic purposes through a mechanism beyond chemical action. Devices
+include implantable objects (e.g. pacemakers, stents, artificial
+joints), medical equipment and supplies (e.g. bandages, crutches,
+syringes), other instruments used in medical procedures (e.g. sutures,
+defibrillators) and material used in clinical care (e.g. adhesives, body
+material, dental material, surgical material).</p>
 <p><strong>User Guide</strong></p>
-<p>The distinction between Devices or supplies and Procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.</p>
+<p>The distinction between Devices or supplies and Procedures are
+sometimes blurry, but the former are physical objects while the latter
+are actions, often to apply a Device or supply.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Source codes and source text fields mapped to Standard Concepts of the Device Domain have to be recorded here.</p>
+<p>Source codes and source text fields mapped to Standard Concepts of
+the Device Domain have to be recorded here.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -3930,10 +4657,12 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_exposure_id
 </td>
 <td style="text-align:left;">
-The unique key given to records a person’s exposure to a foreign physical object or instrument.
+The unique key given to records a person’s exposure to a foreign
+physical object or instrument.
 </td>
 <td style="text-align:left;">
-Each instance of an exposure to a foreign object or device present in the source data should be assigned this unique key.
+Each instance of an exposure to a foreign object or device present in
+the source data should be assigned this unique key.
 </td>
 <td style="text-align:left;">
 integer
@@ -3983,7 +4712,10 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_concept_id
 </td>
 <td style="text-align:left;">
-The DEVICE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a foreign object or instrument the person was exposed to.
+The DEVICE_CONCEPT_ID field is recommended for primary use in analyses,
+and must be used for network studies. This is the standard concept
+mapped from the source concept id which represents a foreign object or
+instrument the person was exposed to.
 </td>
 <td style="text-align:left;">
 The CONCEPT_ID that the DEVICE_SOURCE_VALUE maps to.
@@ -4015,7 +4747,9 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 Use this date to determine the start date of the device record.
 </td>
 <td style="text-align:left;">
-Valid entries include a start date of a procedure to implant a device, the date of a prescription for a device, or the date of device administration.
+Valid entries include a start date of a procedure to implant a device,
+the date of a prescription for a device, or the date of device
+administration.
 </td>
 <td style="text-align:left;">
 date
@@ -4041,7 +4775,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -4065,10 +4800,12 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_exposure_end_date
 </td>
 <td style="text-align:left;">
-The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended for the patient, if given.
+The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended
+for the patient, if given.
 </td>
 <td style="text-align:left;">
-Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable.
+Put the end date or discontinuation date as it appears from the source
+data or leave blank if unavailable.
 </td>
 <td style="text-align:left;">
 date
@@ -4094,7 +4831,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+If a source does not specify datetime the convention is to set the time
+to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -4118,10 +4856,15 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_type_concept_id
 </td>
 <td style="text-align:left;">
-You can use the TYPE_CONCEPT_ID to denote the provenance of the record, as in whether the record is from administrative claims or EHR.
+You can use the TYPE_CONCEPT_ID to denote the provenance of the record,
+as in whether the record is from administrative claims or EHR.
 </td>
 <td style="text-align:left;">
-Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the drug_type_concept_id that best represents the provenance of
+the record, for example whether it came from a record of a prescription
+written or physician administered drug. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -4147,10 +4890,13 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 unique_device_id
 </td>
 <td style="text-align:left;">
-This is the Unique Device Identification number for devices regulated by the FDA, if given.
+This is the Unique Device Identification number for devices regulated by
+the FDA, if given.
 </td>
 <td style="text-align:left;">
-For medical devices that are regulated by the FDA, a Unique Device Identification (UDI) is provided if available in the data source and is recorded in the UNIQUE_DEVICE_ID field.
+For medical devices that are regulated by the FDA, a Unique Device
+Identification (UDI) is provided if available in the data source and is
+recorded in the UNIQUE_DEVICE_ID field.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4199,10 +4945,13 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The Provider associated with device record, e.g. the provider who wrote the prescription or the provider who implanted the device.
+The Provider associated with device record, e.g. the provider who wrote
+the prescription or the provider who implanted the device.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record.
 </td>
 <td style="text-align:left;">
 integer
@@ -4230,7 +4979,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 The Visit during which the device was prescribed or given.
 </td>
 <td style="text-align:left;">
-To populate this field device exposures must be explicitly initiated in the visit.
+To populate this field device exposures must be explicitly initiated in
+the visit.
 </td>
 <td style="text-align:left;">
 integer
@@ -4258,7 +5008,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 The Visit Detail during which the device was prescribed or given.
 </td>
 <td style="text-align:left;">
-To populate this field device exposures must be explicitly initiated in the visit detail record.
+To populate this field device exposures must be explicitly initiated in
+the visit detail record.
 </td>
 <td style="text-align:left;">
 integer
@@ -4283,10 +5034,13 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the device exposure that occurred. For example, this could be an NDC or Gemscript code.
+This field houses the verbatim value from the source data representing
+the device exposure that occurred. For example, this could be an NDC or
+Gemscript code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Device Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4310,10 +5064,19 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the device source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Device necessary for a given analytic use case. Consider using DEVICE_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the device source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Device
+necessary for a given analytic use case. Consider using
+DEVICE_CONCEPT_ID instead to enable standardized analytics that can be
+consistent across the network.
 </td>
 <td style="text-align:left;">
-If the DEVICE_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the DEVICE_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -4339,11 +5102,47 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <div id="measurement" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <p><strong>Table Description</strong></p>
-<p>The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a PROCEDURE_OCCURRENCE record for each measurement if one does not exist in the source data. Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. If there is no result, it is assumed that the lab test was conducted but the result was not captured.</p>
+<p>The MEASUREMENT table contains records of Measurements,
+i.e. structured values (numerical or categorical) obtained through
+systematic and standardized examination or testing of a Person or
+Person’s sample. The MEASUREMENT table contains both orders and results
+of such Measurements as laboratory tests, vital signs, quantitative
+findings from pathology reports, etc. Measurements are stored as
+attribute value pairs, with the attribute as the Measurement Concept and
+the value representing the result. The value can be a Concept (stored in
+VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit
+(UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in
+the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a
+PROCEDURE_OCCURRENCE record for each measurement if one does not exist
+in the source data. Measurements differ from Observations in that they
+require a standardized test or some other activity to generate a
+quantitative or qualitative result. If there is no result, it is assumed
+that the lab test was conducted but the result was not captured.</p>
 <p><strong>User Guide</strong></p>
-<p>Measurements are predominately lab tests with a few exceptions, like blood pressure or function tests. Results are given in the form of a value and unit combination. When investigating measurements, look for operator_concept_ids (&lt;, &gt;, etc.).</p>
+<p>Measurements are predominately lab tests with a few exceptions, like
+blood pressure or function tests. Results are given in the form of a
+value and unit combination. When investigating measurements, look for
+operator_concept_ids (&lt;, &gt;, etc.).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Only records where the source value maps to a Concept in the measurement domain should be included in this table. Even though each Measurement always has a result, the fields VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are not mandatory as often the result is not given in the source data. When the result is not known, the Measurement record represents just the fact that the corresponding Measurement was carried out, which in itself is already useful information for some use cases. For some Measurement Concepts, the result is included in the test. For example, ICD10 CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/45548980">45548980</a> ‘Abnormal level of unspecified serum enzyme’ indicates a Measurement and the result (abnormal). In those situations, the CONCEPT_RELATIONSHIP table in addition to the ‘Maps to’ record contains a second record with the relationship_id set to ‘Maps to value’. In this example, the ‘Maps to’ relationship directs to <a href="https://athena.ohdsi.org/search-terms/terms/4046263">4046263</a> ‘Enzyme measurement’ as well as a ‘Maps to value’ record to <a href="https://athena.ohdsi.org/search-terms/terms/4135493">4135493</a> ‘Abnormal’.</p>
+<p>Only records where the source value maps to a Concept in the
+measurement domain should be included in this table. Even though each
+Measurement always has a result, the fields VALUE_AS_NUMBER and
+VALUE_AS_CONCEPT_ID are not mandatory as often the result is not given
+in the source data. When the result is not known, the Measurement record
+represents just the fact that the corresponding Measurement was carried
+out, which in itself is already useful information for some use cases.
+For some Measurement Concepts, the result is included in the test. For
+example, ICD10 CONCEPT_ID <a
+href="https://athena.ohdsi.org/search-terms/terms/45548980">45548980</a>
+‘Abnormal level of unspecified serum enzyme’ indicates a Measurement and
+the result (abnormal). In those situations, the CONCEPT_RELATIONSHIP
+table in addition to the ‘Maps to’ record contains a second record with
+the relationship_id set to ‘Maps to value’. In this example, the ‘Maps
+to’ relationship directs to <a
+href="https://athena.ohdsi.org/search-terms/terms/4046263">4046263</a>
+‘Enzyme measurement’ as well as a ‘Maps to value’ record to <a
+href="https://athena.ohdsi.org/search-terms/terms/4135493">4135493</a>
+‘Abnormal’.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -4382,10 +5181,15 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_id
 </td>
 <td style="text-align:left;">
-The unique key given to a Measurement record for a Person. Refer to the ETL for how duplicate Measurements during the same Visit were handled.
+The unique key given to a Measurement record for a Person. Refer to the
+ETL for how duplicate Measurements during the same Visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a measurement present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same measurement within the same visit. It is valid to keep these duplicates and assign them individual, unique, MEASUREMENT_IDs, though it is up to the ETL how they should be handled.
+Each instance of a measurement present in the source data should be
+assigned this unique key. In some cases, a person can have multiple
+records of the same measurement within the same visit. It is valid to
+keep these duplicates and assign them individual, unique,
+MEASUREMENT_IDs, though it is up to the ETL how they should be handled.
 </td>
 <td style="text-align:left;">
 integer
@@ -4409,7 +5213,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the Person for whom the Measurement is recorded. This may be a system generated code.
+The PERSON_ID of the Person for whom the Measurement is recorded. This
+may be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -4436,10 +5241,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_concept_id
 </td>
 <td style="text-align:left;">
-The MEASUREMENT_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
+The MEASUREMENT_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain of “Measurement” should go in this table.
+The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only
+records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain
+of “Measurement” should go in this table.
 </td>
 <td style="text-align:left;">
 integer
@@ -4468,7 +5276,9 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 Use this date to determine the date of the measurement.
 </td>
 <td style="text-align:left;">
-If there are multiple dates in the source data associated with a record such as order_date, draw_date, and result_date, choose the one that is closest to the date the sample was drawn from the patient.
+If there are multiple dates in the source data associated with a record
+such as order_date, draw_date, and result_date, choose the one that is
+closest to the date the sample was drawn from the patient.
 </td>
 <td style="text-align:left;">
 date
@@ -4494,7 +5304,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -4520,7 +5331,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is present for backwards compatibility and will be deprecated in an upcoming version.
+This is present for backwards compatibility and will be deprecated in an
+upcoming version.
 </td>
 <td style="text-align:left;">
 varchar(10)
@@ -4544,10 +5356,16 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Measurement record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Measurement
+record, as in whether the measurement was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the
+provenance of the record, for example whether it came from an EHR record
+or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -4573,10 +5391,18 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 operator_concept_id
 </td>
 <td style="text-align:left;">
-The meaning of Concept <a href="https://athena.ohdsi.org/search-terms/terms/4172703">4172703</a> for ‘=’ is identical to omission of a OPERATOR_CONCEPT_ID value. Since the use of this field is rare, it’s important when devising analyses to not to forget testing for the content of this field for values different from =.
+The meaning of Concept <a
+href="https://athena.ohdsi.org/search-terms/terms/4172703">4172703</a>
+for ‘=’ is identical to omission of a OPERATOR_CONCEPT_ID value. Since
+the use of this field is rare, it’s important when devising analyses to
+not to forget testing for the content of this field for values different
+from =.
 </td>
 <td style="text-align:left;">
-Operators are =, &gt; and these concepts belong to the ‘Meas Value Operator’ domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Operators are =, &gt; and these concepts belong to the ‘Meas Value
+Operator’ domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -4601,10 +5427,29 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 value_as_number
 </td>
 <td style="text-align:left;">
-This is the numerical value of the Result of the Measurement, if available. Note that measurements such as blood pressures will be split into their component parts i.e. one record for systolic, one record for diastolic.
+This is the numerical value of the Result of the Measurement, if
+available. Note that measurements such as blood pressures will be split
+into their component parts i.e. one record for systolic, one record for
+diastolic.
 </td>
 <td style="text-align:left;">
-If there is a negative value coming from the source, set the VALUE_AS_NUMBER to NULL, with the exception of the following Measurements (listed as LOINC codes):<br>- <a href="https://athena.ohdsi.org/search-terms/terms/3003396">1925-7</a> Base excess in Arterial blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3002032">1927-3</a> Base excess in Venous blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3006277">8632-2</a> QRS-Axis - <a href="https://athena.ohdsi.org/search-terms/terms/3012501">11555-0</a> Base excess in Blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3003129">1926-5</a> Base excess in Capillary blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3004959">28638-5</a> Base excess in Arterial cord blood by calculation <a href="https://athena.ohdsi.org/search-terms/terms/3007435">28639-3</a> Base excess in Venous cord blood by calculation
+If there is a negative value coming from the source, set the
+VALUE_AS_NUMBER to NULL, with the exception of the following
+Measurements (listed as LOINC codes):<br>- <a
+href="https://athena.ohdsi.org/search-terms/terms/3003396">1925-7</a>
+Base excess in Arterial blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3002032">1927-3</a>
+Base excess in Venous blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3006277">8632-2</a>
+QRS-Axis - <a
+href="https://athena.ohdsi.org/search-terms/terms/3012501">11555-0</a>
+Base excess in Blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3003129">1926-5</a>
+Base excess in Capillary blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3004959">28638-5</a>
+Base excess in Arterial cord blood by calculation <a
+href="https://athena.ohdsi.org/search-terms/terms/3007435">28639-3</a>
+Base excess in Venous cord blood by calculation
 </td>
 <td style="text-align:left;">
 float
@@ -4628,10 +5473,16 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 value_as_concept_id
 </td>
 <td style="text-align:left;">
-If the raw data gives a categorial result for measurements those values are captured and mapped to standard concepts in the ‘Meas Value’ domain.
+If the raw data gives a categorial result for measurements those values
+are captured and mapped to standard concepts in the ‘Meas Value’ domain.
 </td>
 <td style="text-align:left;">
-If the raw data provides categorial results as well as continuous results for measurements, it is a valid ETL choice to preserve both values. The continuous value should go in the VALUE_AS_NUMBER field and the categorical value should be mapped to a standard concept in the ‘Meas Value’ domain and put in the VALUE_AS_CONCEPT_ID field. This is also the destination for the ‘Maps to value’ relationship.
+If the raw data provides categorial results as well as continuous
+results for measurements, it is a valid ETL choice to preserve both
+values. The continuous value should go in the VALUE_AS_NUMBER field and
+the categorical value should be mapped to a standard concept in the
+‘Meas Value’ domain and put in the VALUE_AS_CONCEPT_ID field. This is
+also the destination for the ‘Maps to value’ relationship.
 </td>
 <td style="text-align:left;">
 integer
@@ -4656,10 +5507,16 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 unit_concept_id
 </td>
 <td style="text-align:left;">
-There is currently no recommended unit for individual measurements, i.e. it is not mandatory to represent Hemoglobin a1C measurements as a percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit domain that best represents the unit as given in the source data.
+There is currently no recommended unit for individual measurements,
+i.e. it is not mandatory to represent Hemoglobin a1C measurements as a
+percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in
+the Unit domain that best represents the unit as given in the source
+data.
 </td>
 <td style="text-align:left;">
-There is no standardization requirement for units associated with MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to choose the most plausible unit.
+There is no standardization requirement for units associated with
+MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to
+choose the most plausible unit.
 </td>
 <td style="text-align:left;">
 integer
@@ -4685,10 +5542,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 range_low
 </td>
 <td style="text-align:left;">
-Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and should remain NULL if not given.
+Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are
+provided by the source and should remain NULL if not given.
 </td>
 <td style="text-align:left;">
-If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the RANGE_HIGH and RANGE_LOW fields. This should be set to NULL if not provided.
+If reference ranges for upper and lower limit of normal as provided
+(typically by a laboratory) these are stored in the RANGE_HIGH and
+RANGE_LOW fields. This should be set to NULL if not provided.
 </td>
 <td style="text-align:left;">
 float
@@ -4712,10 +5572,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 range_high
 </td>
 <td style="text-align:left;">
-Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and should remain NULL if not given.
+Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are
+provided by the source and should remain NULL if not given.
 </td>
 <td style="text-align:left;">
-If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the RANGE_HIGH and RANGE_LOW fields. This should be set to NULL if not provided.
+If reference ranges for upper and lower limit of normal as provided
+(typically by a laboratory) these are stored in the RANGE_HIGH and
+RANGE_LOW fields. This should be set to NULL if not provided.
 </td>
 <td style="text-align:left;">
 float
@@ -4739,10 +5602,14 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with measurement record, e.g. the provider who ordered the test or the provider who recorded the result.
+The provider associated with measurement record, e.g. the provider who
+ordered the test or the provider who recorded the result.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record. For
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -4770,7 +5637,15 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 The visit during which the Measurement occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If a MEASUREMENT_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a measurement is related to a visit explicitly in the source data, it is possible that the result date of the Measurement falls outside of the bounds of the Visit dates.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If a MEASUREMENT_DATE occurs within the start
+and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a
+measurement is related to a visit explicitly in the source data, it is
+possible that the result date of the Measurement falls outside of the
+bounds of the Visit dates.
 </td>
 <td style="text-align:left;">
 integer
@@ -4795,7 +5670,10 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the Measurement occurred. For
+example, if the Person was in the ICU at the time the VISIT_OCCURRENCE
+record would reflect the overall hospital stay and the VISIT_DETAIL
+record would reflect the ICU stay during the hospital visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -4823,10 +5701,14 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the Measurement that occurred. For example, this could be an ICD10 or Read code.
+This field houses the verbatim value from the source data representing
+the Measurement that occurred. For example, this could be an ICD10 or
+Read code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Measurement Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Measurement Concept in the
+Standardized Vocabularies and the original code is stored here for
+reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4850,10 +5732,19 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the MEASUREMENT_SOURCE_VALUE and may
+not necessarily be standard. This field is discouraged from use in
+analysis because it is not required to contain Standard Concepts that
+are used across the OHDSI community, and should only be used when
+Standard Concepts do not adequately represent the source detail for the
+Measurement necessary for a given analytic use case. Consider using
+MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the MEASUREMENT_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the MEASUREMENT_SOURCE_VALUE is coded in the source data using an
+OMOP supported vocabulary put the concept id representing the source
+value here.
 </td>
 <td style="text-align:left;">
 integer
@@ -4878,10 +5769,12 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the unit of the Measurement that occurred.
+This field houses the verbatim value from the source data representing
+the unit of the Measurement that occurred.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4905,10 +5798,14 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 value_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim result value of the Measurement from the source data .
+This field houses the verbatim result value of the Measurement from the
+source data .
 </td>
 <td style="text-align:left;">
-If both a continuous and categorical result are given in the source data such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both included, store the verbatim value that was mapped to VALUE_AS_CONCEPT_ID here.
+If both a continuous and categorical result are given in the source data
+such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both
+included, store the verbatim value that was mapped to
+VALUE_AS_CONCEPT_ID here.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4933,11 +5830,35 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <div id="observation" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">OBSERVATION</h3>
 <p><strong>Table Description</strong></p>
-<p>The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here.</p>
+<p>The OBSERVATION table captures clinical facts about a Person obtained
+in the context of examination, questioning or a procedure. Any data that
+cannot be represented by any other domains, such as social and lifestyle
+facts, medical history, family history, etc. are recorded here.</p>
 <p><strong>User Guide</strong></p>
-<p>Observations differ from Measurements in that they do not require a standardized test or some other activity to generate clinical fact. Typical observations are medical history, family history, the stated need for certain treatment, social circumstances, lifestyle choices, healthcare utilization patterns, etc. If the generation clinical facts requires a standardized testing such as lab testing or imaging and leads to a standardized result, the data item is recorded in the MEASUREMENT table. If the clinical fact observed determines a sign, symptom, diagnosis of a disease or other medical condition, it is recorded in the CONDITION_OCCURRENCE table. Valid Observation Concepts are not enforced to be from any domain though they still should be Standard Concepts.</p>
+<p>Observations differ from Measurements in that they do not require a
+standardized test or some other activity to generate clinical fact.
+Typical observations are medical history, family history, the stated
+need for certain treatment, social circumstances, lifestyle choices,
+healthcare utilization patterns, etc. If the generation clinical facts
+requires a standardized testing such as lab testing or imaging and leads
+to a standardized result, the data item is recorded in the MEASUREMENT
+table. If the clinical fact observed determines a sign, symptom,
+diagnosis of a disease or other medical condition, it is recorded in the
+CONDITION_OCCURRENCE table. Valid Observation Concepts are not enforced
+to be from any domain though they still should be Standard Concepts.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Records whose Source Values map to any domain besides Condition, Procedure, Drug, Measurement or Device should be stored in the Observation table. Observations can be stored as attribute value pairs, with the attribute as the Observation Concept and the value representing the clinical fact. This fact can be a Concept (stored in VALUE_AS_CONCEPT), a numerical value (VALUE_AS_NUMBER), a verbatim string (VALUE_AS_STRING), or a datetime (VALUE_AS_DATETIME). Even though Observations do not have an explicit result, the clinical fact can be stated separately from the type of Observation in the VALUE_AS_* fields. It is recommended for Observations that are suggestive statements of positive assertion should have a value of ‘Yes’ (concept_id=4188539), recorded, even though the null value is the equivalent.</p>
+<p>Records whose Source Values map to any domain besides Condition,
+Procedure, Drug, Measurement or Device should be stored in the
+Observation table. Observations can be stored as attribute value pairs,
+with the attribute as the Observation Concept and the value representing
+the clinical fact. This fact can be a Concept (stored in
+VALUE_AS_CONCEPT), a numerical value (VALUE_AS_NUMBER), a verbatim
+string (VALUE_AS_STRING), or a datetime (VALUE_AS_DATETIME). Even though
+Observations do not have an explicit result, the clinical fact can be
+stated separately from the type of Observation in the VALUE_AS_* fields.
+It is recommended for Observations that are suggestive statements of
+positive assertion should have a value of ‘Yes’ (concept_id=4188539),
+recorded, even though the null value is the equivalent.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -4976,10 +5897,12 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_id
 </td>
 <td style="text-align:left;">
-The unique key given to an Observation record for a Person. Refer to the ETL for how duplicate Observations during the same Visit were handled.
+The unique key given to an Observation record for a Person. Refer to the
+ETL for how duplicate Observations during the same Visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of an observation present in the source data should be assigned this unique key.
+Each instance of an observation present in the source data should be
+assigned this unique key.
 </td>
 <td style="text-align:left;">
 integer
@@ -5003,7 +5926,8 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the Person for whom the Observation is recorded. This may be a system generated code.
+The PERSON_ID of the Person for whom the Observation is recorded. This
+may be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5030,10 +5954,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_concept_id
 </td>
 <td style="text-align:left;">
-The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
+The OBSERVATION_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domains MUST go to the corresponding table.
+The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is
+no specified domain that the Concepts in this table must adhere to. The
+only rule is that records with Concepts in the Condition, Procedure,
+Drug, Measurement, or Device domains MUST go to the corresponding table.
 </td>
 <td style="text-align:left;">
 integer
@@ -5058,10 +5986,13 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_date
 </td>
 <td style="text-align:left;">
-The date of the Observation. Depending on what the Observation represents this could be the date of a lab test, the date of a survey, or the date a patient’s family history was taken.
+The date of the Observation. Depending on what the Observation
+represents this could be the date of a lab test, the date of a survey,
+or the date a patient’s family history was taken.
 </td>
 <td style="text-align:left;">
-For some observations the ETL may need to make a choice as to which date to choose.
+For some observations the ETL may need to make a choice as to which date
+to choose.
 </td>
 <td style="text-align:left;">
 date
@@ -5111,10 +6042,16 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Observation record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Observation
+record, as in whether the measurement was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the
+provenance of the record, for example whether it came from an EHR record
+or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -5140,7 +6077,10 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_number
 </td>
 <td style="text-align:left;">
-This is the numerical value of the Result of the Observation, if applicable and available. It is not expected that all Observations will have numeric results, rather, this field is here to house values should they exist.
+This is the numerical value of the Result of the Observation, if
+applicable and available. It is not expected that all Observations will
+have numeric results, rather, this field is here to house values should
+they exist.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5166,7 +6106,8 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_string
 </td>
 <td style="text-align:left;">
-This is the categorical value of the Result of the Observation, if applicable and available.
+This is the categorical value of the Result of the Observation, if
+applicable and available.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5192,10 +6133,29 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_concept_id
 </td>
 <td style="text-align:left;">
-It is possible that some records destined for the Observation table have two clinical ideas represented in one source code. This is common with ICD10 codes that describe a family history of some Condition, for example. In OMOP the Vocabulary breaks these two clinical ideas into two codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the VALUE_AS_CONCEPT_ID. It is important when using the Observation table to keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID field for relevant information.
+It is possible that some records destined for the Observation table have
+two clinical ideas represented in one source code. This is common with
+ICD10 codes that describe a family history of some Condition, for
+example. In OMOP the Vocabulary breaks these two clinical ideas into two
+codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the
+VALUE_AS_CONCEPT_ID. It is important when using the Observation table to
+keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID
+field for relevant information.
 </td>
 <td style="text-align:left;">
-Note that the value of VALUE_AS_CONCEPT_ID may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the ‘Maps to’ record contains a second record with the relationship_id set to ‘Maps to value’. For example, ICD10 <a href="https://athena.ohdsi.org/search-terms/terms/45581076">Z82.4</a> ‘Family history of ischaemic heart disease and other diseases of the circulatory system’ has a ‘Maps to’ relationship to <a href="https://athena.ohdsi.org/search-terms/terms/4167217">4167217</a> ‘Family history of clinical finding’ as well as a ‘Maps to value’ record to <a href="https://athena.ohdsi.org/search-terms/terms/134057">134057</a> ‘Disorder of cardiovascular system’.
+Note that the value of VALUE_AS_CONCEPT_ID may be provided through
+mapping from a source Concept which contains the content of the
+Observation. In those situations, the CONCEPT_RELATIONSHIP table in
+addition to the ‘Maps to’ record contains a second record with the
+relationship_id set to ‘Maps to value’. For example, ICD10 <a
+href="https://athena.ohdsi.org/search-terms/terms/45581076">Z82.4</a>
+‘Family history of ischaemic heart disease and other diseases of the
+circulatory system’ has a ‘Maps to’ relationship to <a
+href="https://athena.ohdsi.org/search-terms/terms/4167217">4167217</a>
+‘Family history of clinical finding’ as well as a ‘Maps to value’ record
+to <a
+href="https://athena.ohdsi.org/search-terms/terms/134057">134057</a>
+‘Disorder of cardiovascular system’.
 </td>
 <td style="text-align:left;">
 Integer
@@ -5220,10 +6180,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 qualifier_concept_id
 </td>
 <td style="text-align:left;">
-This field contains all attributes specifying the clinical fact further, such as as degrees, severities, drug-drug interaction alerts etc.
+This field contains all attributes specifying the clinical fact further,
+such as as degrees, severities, drug-drug interaction alerts etc.
 </td>
 <td style="text-align:left;">
-Use your best judgement as to what Concepts to use here and if they are necessary to accurately represent the clinical record. There is no restriction on the domain of these Concepts, they just need to be Standard.
+Use your best judgement as to what Concepts to use here and if they are
+necessary to accurately represent the clinical record. There is no
+restriction on the domain of these Concepts, they just need to be
+Standard.
 </td>
 <td style="text-align:left;">
 integer
@@ -5248,10 +6212,15 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 unit_concept_id
 </td>
 <td style="text-align:left;">
-There is currently no recommended unit for individual observation concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit domain that best represents the unit as given in the source data.
+There is currently no recommended unit for individual observation
+concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in
+the Unit domain that best represents the unit as given in the source
+data.
 </td>
 <td style="text-align:left;">
-There is no standardization requirement for units associated with OBSERVATION_CONCEPT_IDs, however, it is the responsibility of the ETL to choose the most plausible unit.
+There is no standardization requirement for units associated with
+OBSERVATION_CONCEPT_IDs, however, it is the responsibility of the ETL to
+choose the most plausible unit.
 </td>
 <td style="text-align:left;">
 integer
@@ -5277,10 +6246,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with the observation record, e.g. the provider who ordered the test or the provider who recorded the result.
+The provider associated with the observation record, e.g. the provider
+who ordered the test or the provider who recorded the result.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record. For
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -5308,7 +6281,15 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 The visit during which the Observation occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If an OBSERVATION_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the observation record. If an observation is related to a visit explicitly in the source data, it is possible that the result date of the Observation falls outside of the bounds of the Visit dates.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If an OBSERVATION_DATE occurs within the
+start and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the observation record. If an
+observation is related to a visit explicitly in the source data, it is
+possible that the result date of the Observation falls outside of the
+bounds of the Visit dates.
 </td>
 <td style="text-align:left;">
 integer
@@ -5333,7 +6314,10 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the Observation occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the Observation occurred. For
+example, if the Person was in the ICU at the time the VISIT_OCCURRENCE
+record would reflect the overall hospital stay and the VISIT_DETAIL
+record would reflect the ICU stay during the hospital visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -5361,10 +6345,13 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the Observation that occurred. For example, this could be an ICD10 or Read code.
+This field houses the verbatim value from the source data representing
+the Observation that occurred. For example, this could be an ICD10 or
+Read code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5388,10 +6375,19 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the OBSERVATION_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Observation necessary for a given analytic use case. Consider using OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the OBSERVATION_SOURCE_VALUE and may
+not necessarily be standard. This field is discouraged from use in
+analysis because it is not required to contain Standard Concepts that
+are used across the OHDSI community, and should only be used when
+Standard Concepts do not adequately represent the source detail for the
+Observation necessary for a given analytic use case. Consider using
+OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the OBSERVATION_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the OBSERVATION_SOURCE_VALUE is coded in the source data using an
+OMOP supported vocabulary put the concept id representing the source
+value here.
 </td>
 <td style="text-align:left;">
 integer
@@ -5416,10 +6412,12 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the unit of the Observation that occurred.
+This field houses the verbatim value from the source data representing
+the unit of the Observation that occurred.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5443,10 +6441,12 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 qualifier_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the qualifier of the Observation that occurred.
+This field houses the verbatim value from the source data representing
+the qualifier of the Observation that occurred.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5471,7 +6471,11 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 <div id="death" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DEATH</h3>
 <p><strong>Table Description</strong></p>
-<p>The death domain contains the clinical event for how and when a Person dies. A person can have up to one record if the source system contains evidence about the Death, such as: Condition in an administrative claim, status of enrollment into a health plan, or explicit record in EHR data.</p>
+<p>The death domain contains the clinical event for how and when a
+Person dies. A person can have up to one record if the source system
+contains evidence about the Death, such as: Condition in an
+administrative claim, status of enrollment into a health plan, or
+explicit record in EHR data.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -5539,7 +6543,9 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 The date the person was deceased.
 </td>
 <td style="text-align:left;">
-If the precise date include day or month is not known or not allowed, December is used as the default month, and the last day of the month the default day.
+If the precise date include day or month is not known or not allowed,
+December is used as the default month, and the last day of the month the
+default day.
 </td>
 <td style="text-align:left;">
 date
@@ -5589,10 +6595,15 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 death_type_concept_id
 </td>
 <td style="text-align:left;">
-This is the provenance of the death record, i.e., where it came from. It is possible that an administrative claims database would source death information from a government file so do not assume the Death Type is the same as the Visit Type, etc.
+This is the provenance of the death record, i.e., where it came from. It
+is possible that an administrative claims database would source death
+information from a government file so do not assume the Death Type is
+the same as the Visit Type, etc.
 </td>
 <td style="text-align:left;">
-Use the type concept that be reflects the source of the death record. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Use the type concept that be reflects the source of the death record. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -5618,10 +6629,12 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 cause_concept_id
 </td>
 <td style="text-align:left;">
-This is the Standard Concept representing the Person’s cause of death, if available.
+This is the Standard Concept representing the Person’s cause of death,
+if available.
 </td>
 <td style="text-align:left;">
-There is no specified domain for this concept, just choose the Standard Concept Id that best represents the person’s cause of death.
+There is no specified domain for this concept, just choose the Standard
+Concept Id that best represents the person’s cause of death.
 </td>
 <td style="text-align:left;">
 integer
@@ -5674,7 +6687,8 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the cause of death was coded using a Vocabulary present in the OMOP Vocabularies put the CONCEPT_ID representing the cause of death here.
+If the cause of death was coded using a Vocabulary present in the OMOP
+Vocabularies put the CONCEPT_ID representing the cause of death here.
 </td>
 <td style="text-align:left;">
 integer
@@ -5700,17 +6714,38 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 <div id="note" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">NOTE</h3>
 <p><strong>Table Description</strong></p>
-<p>The NOTE table captures unstructured information that was recorded by a provider about a patient in free text (in ASCII, or preferably in UTF8 format) notes on a given date. The type of note_text is CLOB or varchar(MAX) depending on RDBMS.</p>
+<p>The NOTE table captures unstructured information that was recorded by
+a provider about a patient in free text (in ASCII, or preferably in UTF8
+format) notes on a given date. The type of note_text is CLOB or
+varchar(MAX) depending on RDBMS.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>HL7/LOINC CDO is a standard for consistent naming of documents to support a range of use cases: retrieval, organization, display, and exchange. It guides the creation of LOINC codes for clinical notes. CDO annotates each document with 5 dimensions:</p>
+<p>HL7/LOINC CDO is a standard for consistent naming of documents to
+support a range of use cases: retrieval, organization, display, and
+exchange. It guides the creation of LOINC codes for clinical notes. CDO
+annotates each document with 5 dimensions:</p>
 <ul>
-<li><strong>Kind of Document</strong>: Characterizes the general structure of the document at a macro level (e.g. Anesthesia Consent)</li>
-<li><strong>Type of Service</strong>: Characterizes the kind of service or activity (e.g. evaluations, consultations, and summaries). The notion of time sequence, e.g., at the beginning (admission) at the end (discharge) is subsumed in this axis. Example: Discharge Teaching.</li>
-<li><strong>Setting</strong>: Setting is an extension of CMS’s definitions (e.g. Inpatient, Outpatient)</li>
-<li><strong>Subject Matter Domain (SMD)</strong>: Characterizes the subject matter domain of a note (e.g. Anesthesiology)</li>
-<li><strong>Role</strong>: Characterizes the training or professional level of the author of the document, but does not break down to specialty or subspecialty (e.g. Physician) Each combination of these 5 dimensions rolls up to a unique LOINC code.</li>
+<li><strong>Kind of Document</strong>: Characterizes the general
+structure of the document at a macro level (e.g. Anesthesia
+Consent)</li>
+<li><strong>Type of Service</strong>: Characterizes the kind of service
+or activity (e.g. evaluations, consultations, and summaries). The notion
+of time sequence, e.g., at the beginning (admission) at the end
+(discharge) is subsumed in this axis. Example: Discharge Teaching.</li>
+<li><strong>Setting</strong>: Setting is an extension of CMS’s
+definitions (e.g. Inpatient, Outpatient)</li>
+<li><strong>Subject Matter Domain (SMD)</strong>: Characterizes the
+subject matter domain of a note (e.g. Anesthesiology)</li>
+<li><strong>Role</strong>: Characterizes the training or professional
+level of the author of the document, but does not break down to
+specialty or subspecialty (e.g. Physician) Each combination of these 5
+dimensions rolls up to a unique LOINC code.</li>
 </ul>
-<p>According to CDO requirements, only 2 of the 5 dimensions are required to properly annotate a document; Kind of Document and any one of the other 4 dimensions. However, not all the permutations of the CDO dimensions will necessarily yield an existing LOINC code. Each of these dimensions are contained in the OMOP Vocabulary under the domain of ‘Meas Value’ with each dimension represented as a Concept Class.</p>
+<p>According to CDO requirements, only 2 of the 5 dimensions are
+required to properly annotate a document; Kind of Document and any one
+of the other 4 dimensions. However, not all the permutations of the CDO
+dimensions will necessarily yield an existing LOINC code. Each of these
+dimensions are contained in the OMOP Vocabulary under the domain of
+‘Meas Value’ with each dimension represented as a Concept Class.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -5856,7 +6891,9 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 The provenance of the note. Most likely this will be EHR.
 </td>
 <td style="text-align:left;">
-Put the source system of the note, as in EHR record. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Put the source system of the note, as in EHR record. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -5882,10 +6919,17 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 note_class_concept_id
 </td>
 <td style="text-align:left;">
-A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note.
+A Standard Concept Id representing the HL7 LOINC Document Type
+Vocabulary classification of the note.
 </td>
 <td style="text-align:left;">
-Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note).
+Map the note classification to a Standard Concept. For more information
+see the ETL Conventions in the description of the NOTE table. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. This Concept can alternatively be represented by concepts
+with the relationship ‘Kind of (LOINC)’ to <a
+href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a>
+(Note).
 </td>
 <td style="text-align:left;">
 integer
@@ -5965,7 +7009,10 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 This is the Concept representing the character encoding type.
 </td>
 <td style="text-align:left;">
-Put the Concept Id that represents the encoding character type here. Currently the only option is UTF-8 (<a href="https://athena.ohdsi.org/search-terms/terms/32678">32678</a>). It the note is encoded in any other type, like ASCII then put 0.
+Put the Concept Id that represents the encoding character type here.
+Currently the only option is UTF-8 (<a
+href="https://athena.ohdsi.org/search-terms/terms/32678">32678</a>). It
+the note is encoded in any other type, like ASCII then put 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -5993,7 +7040,9 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 The language of the note.
 </td>
 <td style="text-align:left;">
-Use Concepts that are descendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages).
+Use Concepts that are descendants of the concept <a
+href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a>
+(World Languages).
 </td>
 <td style="text-align:left;">
 integer
@@ -6127,7 +7176,8 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 <div id="note_nlp" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <p><strong>Table Description</strong></p>
-<p>The NOTE_NLP table encodes all output of NLP on clinical notes. Each row represents a single extracted term from a note.</p>
+<p>The NOTE_NLP table encodes all output of NLP on clinical notes. Each
+row represents a single extracted term from a note.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -6220,7 +7270,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The SECTION_CONCEPT_ID should be used to represent the note section contained in the NOTE_NLP record. These concepts can be found as parts of document panels and are based on the type of note written, i.e. a discharge summary. These panels can be found as concepts with the relationship ‘Subsumes’ to CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
+The SECTION_CONCEPT_ID should be used to represent the note section
+contained in the NOTE_NLP record. These concepts can be found as parts
+of document panels and are based on the type of note written, i.e. a
+discharge summary. These panels can be found as concepts with the
+relationship ‘Subsumes’ to CONCEPT_ID <a
+href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -6377,7 +7432,8 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Name and version of the NLP system that extracted the term. Useful for data provenance.
+Name and version of the NLP system that extracted the term. Useful for
+data provenance.
 </td>
 <td style="text-align:left;">
 varchar(250)
@@ -6455,7 +7511,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Term_exists is defined as a flag that indicates if the patient actually has or had the condition. Any of the following modifiers would make Term_exists false: Negation = true Subject = [anything other than the patient] Conditional = true/li&gt; Rule_out = true Uncertain = very low certainty or any lower certainties A complete lack of modifiers would make Term_exists true.
+Term_exists is defined as a flag that indicates if the patient actually
+has or had the condition. Any of the following modifiers would make
+Term_exists false: Negation = true Subject = [anything other than the
+patient] Conditional = true/li&gt; Rule_out = true Uncertain = very low
+certainty or any lower certainties A complete lack of modifiers would
+make Term_exists true.
 </td>
 <td style="text-align:left;">
 varchar(1)
@@ -6481,7 +7542,9 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Term_temporal is to indicate if a condition is present or just in the past. The following would be past:<br><br> - History = true - Concept_date = anything before the time of the report
+Term_temporal is to indicate if a condition is present or just in the
+past. The following would be past:<br><br> - History = true -
+Concept_date = anything before the time of the report
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -6507,7 +7570,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-For the modifiers that are there, they would have to have these values:<br><br> - Negation = false - Subject = patient - Conditional = false - Rule_out = false - Uncertain = true or high or moderate or even low (could argue about low). Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers.
+For the modifiers that are there, they would have to have these
+values:<br><br> - Negation = false - Subject = patient - Conditional =
+false - Rule_out = false - Uncertain = true or high or moderate or even
+low (could argue about low). Term_modifiers will concatenate all
+modifiers for different types of entities (conditions, drugs, labs etc)
+into one string. Lab values will be saved as one of the modifiers.
 </td>
 <td style="text-align:left;">
 varchar(2000)
@@ -6532,9 +7600,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <div id="specimen" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <p><strong>Table Description</strong></p>
-<p>The specimen domain contains the records identifying biological samples from a person.</p>
+<p>The specimen domain contains the records identifying biological
+samples from a person.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Anatomic site is coded at the most specific level of granularity possible, such that higher level classifications can be derived using the Standardized Vocabularies.</p>
+<p>Anatomic site is coded at the most specific level of granularity
+possible, such that higher level classifications can be derived using
+the Standardized Vocabularies.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -6628,7 +7699,10 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the specimen domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the
+specimen domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -6655,7 +7729,9 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Put the source of the specimen record, as in an EHR system. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Put the source of the specimen record, as in an EHR system. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -6761,7 +7837,9 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 The unit for the quantity of the specimen.
 </td>
 <td style="text-align:left;">
-Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -6789,7 +7867,11 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 This is the site on the body where the specimen is from.
 </td>
 <td style="text-align:left;">
-Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec Anatomic Site domain. This should be coded at the lowest level of granularity <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Spec+Anatomic+Site&amp;conceptClass=Body+Structure&amp;page=4&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec
+Anatomic Site domain. This should be coded at the lowest level of
+granularity <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Spec+Anatomic+Site&amp;conceptClass=Body+Structure&amp;page=4&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -6893,7 +7975,8 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This unit for the quantity of the specimen, as represented in the source.
+This unit for the quantity of the specimen, as represented in the
+source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -6919,7 +8002,8 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is the site on the body where the specimen was taken from, as represented in the source.
+This is the site on the body where the specimen was taken from, as
+represented in the source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -6969,9 +8053,24 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <div id="fact_relationship" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">FACT_RELATIONSHIP</h3>
 <p><strong>Table Description</strong></p>
-<p>The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains. Examples of Fact Relationships include: <a href="https://athena.ohdsi.org/search-terms/terms?domain=Relationship&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Person relationships</a> (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).</p>
+<p>The FACT_RELATIONSHIP table contains records about the relationships
+between facts stored as records in any table of the CDM. Relationships
+can be defined between facts from the same domain, or different domains.
+Examples of Fact Relationships include: <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Relationship&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Person
+relationships</a> (parent-child), care site relationships (hierarchical
+organizational structure of facilities within a health system),
+indication relationship (between drug exposures and associated
+conditions), usage relationships (of devices during the course of an
+associated procedure), or facts derived from one another (measurements
+derived from an associated specimen).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>All relationships are directional, and each relationship is represented twice symmetrically within the FACT_RELATIONSHIP table. For example, two persons if person_id = 1 is the mother of person_id = 2 two records are in the FACT_RELATIONSHIP table (all strings in fact concept_id records in the Concept table: - Person, 1, Person, 2, parent of - Person, 2, Person, 1, child of</p>
+<p>All relationships are directional, and each relationship is
+represented twice symmetrically within the FACT_RELATIONSHIP table. For
+example, two persons if person_id = 1 is the mother of person_id = 2 two
+records are in the FACT_RELATIONSHIP table (all strings in fact
+concept_id records in the Concept table: - Person, 1, Person, 2, parent
+of - Person, 2, Person, 1, child of</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7142,9 +8241,14 @@ <h2><strong>Health System Data Tables</strong></h2>
 <div id="location" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">LOCATION</h3>
 <p><strong>Table Description</strong></p>
-<p>The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites.</p>
+<p>The LOCATION table represents a generic way to capture physical
+location or address information of Persons and Care Sites.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Each address or Location is unique and is present only once in the table. Locations do not contain names, such as the name of a hospital. In order to construct a full address that can be used in the postal service, the address information from the Location needs to be combined with information from the Care Site.</p>
+<p>Each address or Location is unique and is present only once in the
+table. Locations do not contain names, such as the name of a hospital.
+In order to construct a full address that can be used in the postal
+service, the address information from the Location needs to be combined
+with information from the Care Site.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7186,7 +8290,8 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 The unique key given to a unique Location.
 </td>
 <td style="text-align:left;">
-Each instance of a Location in the source data should be assigned this unique key.
+Each instance of a Location in the source data should be assigned this
+unique key.
 </td>
 <td style="text-align:left;">
 integer
@@ -7314,7 +8419,12 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Zip codes are handled as strings of up to 9 characters length. For US addresses, these represent either a 3-digit abbreviated Zip code as provided by many sources for patient protection reasons, the full 5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons analytical methods should expect and utilize only the first 3 digits. For international addresses, different rules apply.
+Zip codes are handled as strings of up to 9 characters length. For US
+addresses, these represent either a 3-digit abbreviated Zip code as
+provided by many sources for patient protection reasons, the full
+5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons
+analytical methods should expect and utilize only the first 3 digits.
+For international addresses, different rules apply.
 </td>
 <td style="text-align:left;">
 varchar(9)
@@ -7365,7 +8475,8 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Put the verbatim value for the location here, as it shows up in the source.
+Put the verbatim value for the location here, as it shows up in the
+source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -7390,9 +8501,23 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 <div id="care_site" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <p><strong>Table Description</strong></p>
-<p>The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).</p>
+<p>The CARE_SITE table contains a list of uniquely identified
+institutional (physical or organizational) units where healthcare
+delivery is practiced (offices, wards, hospitals, clinics, etc.).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Care site is a unique combination of location_id and place_of_service_source_value. Care site does not take into account the provider (human) information such a specialty. Many source data do not make a distinction between individual and institutional providers. The CARE_SITE table contains the institutional providers. If the source, instead of uniquely identifying individual Care Sites, only provides limited information such as Place of Service, generic or “pooled” Care Site records are listed in the CARE_SITE table. There can be hierarchical and business relationships between Care Sites. For example, wards can belong to clinics or departments, which can in turn belong to hospitals, which in turn can belong to hospital systems, which in turn can belong to HMOs.The relationships between Care Sites are defined in the FACT_RELATIONSHIP table.</p>
+<p>Care site is a unique combination of location_id and
+place_of_service_source_value. Care site does not take into account the
+provider (human) information such a specialty. Many source data do not
+make a distinction between individual and institutional providers. The
+CARE_SITE table contains the institutional providers. If the source,
+instead of uniquely identifying individual Care Sites, only provides
+limited information such as Place of Service, generic or “pooled” Care
+Site records are listed in the CARE_SITE table. There can be
+hierarchical and business relationships between Care Sites. For example,
+wards can belong to clinics or departments, which can in turn belong to
+hospitals, which in turn can belong to hospital systems, which in turn
+can belong to HMOs.The relationships between Care Sites are defined in
+the FACT_RELATIONSHIP table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7433,7 +8558,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Assign an id to each unique combination of location_id and place_of_service_source_value
+Assign an id to each unique combination of location_id and
+place_of_service_source_value
 </td>
 <td style="text-align:left;">
 integer
@@ -7483,10 +8609,18 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 place_of_service_concept_id
 </td>
 <td style="text-align:left;">
-This is a high-level way of characterizing a Care Site. Typically, however, Care Sites can provide care in multiple settings (inpatient, outpatient, etc.) and this granularity should be reflected in the visit.
+This is a high-level way of characterizing a Care Site. Typically,
+however, Care Sites can provide care in multiple settings (inpatient,
+outpatient, etc.) and this granularity should be reflected in the visit.
 </td>
 <td style="text-align:left;">
-Choose the concept in the visit domain that best represents the setting in which healthcare is provided in the Care Site. If most visits in a Care Site are Inpatient, then the place_of_service_concept_id should represent Inpatient. If information is present about a unique Care Site (e.g. Pharmacy) then a Care Site record should be created. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the concept in the visit domain that best represents the setting
+in which healthcare is provided in the Care Site. If most visits in a
+Care Site are Inpatient, then the place_of_service_concept_id should
+represent Inpatient. If information is present about a unique Care Site
+(e.g. Pharmacy) then a Care Site record should be created. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -7511,7 +8645,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 location_id
 </td>
 <td style="text-align:left;">
-The location_id from the LOCATION table representing the physical location of the care_site.
+The location_id from the LOCATION table representing the physical
+location of the care_site.
 </td>
 <td style="text-align:left;">
 </td>
@@ -7538,7 +8673,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 care_site_source_value
 </td>
 <td style="text-align:left;">
-The identifier of the care_site as it appears in the source data. This could be an identifier separate from the name of the care_site.
+The identifier of the care_site as it appears in the source data. This
+could be an identifier separate from the name of the care_site.
 </td>
 <td style="text-align:left;">
 </td>
@@ -7566,7 +8702,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Put the place of service of the care_site as it appears in the source data.
+Put the place of service of the care_site as it appears in the source
+data.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -7591,9 +8728,16 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <div id="provider" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PROVIDER</h3>
 <p><strong>Table Description</strong></p>
-<p>The PROVIDER table contains a list of uniquely identified healthcare providers. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc.</p>
+<p>The PROVIDER table contains a list of uniquely identified healthcare
+providers. These are individuals providing hands-on healthcare to
+patients, such as physicians, nurses, midwives, physical therapists
+etc.</p>
 <p><strong>User Guide</strong></p>
-<p>Many sources do not make a distinction between individual and institutional providers. The PROVIDER table contains the individual providers. If the source, instead of uniquely identifying individual providers, only provides limited information such as specialty, generic or ‘pooled’ Provider records are listed in the PROVIDER table.</p>
+<p>Many sources do not make a distinction between individual and
+institutional providers. The PROVIDER table contains the individual
+providers. If the source, instead of uniquely identifying individual
+providers, only provides limited information such as specialty, generic
+or ‘pooled’ Provider records are listed in the PROVIDER table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7632,10 +8776,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently.
+It is assumed that every provider with a different unique identifier is
+in fact a different person and should be treated independently.
 </td>
 <td style="text-align:left;">
-This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number.
+This identifier can be the original id from the source data provided it
+is an integer, otherwise it can be an autogenerated number.
 </td>
 <td style="text-align:left;">
 integer
@@ -7661,7 +8807,9 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This field is not necessary as it is not necessary to have the actual identity of the Provider. Rather, the idea is to uniquely and anonymously identify providers of care across the database.
+This field is not necessary as it is not necessary to have the actual
+identity of the Provider. Rather, the idea is to uniquely and
+anonymously identify providers of care across the database.
 </td>
 <td style="text-align:left;">
 varchar(255)
@@ -7685,7 +8833,8 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 npi
 </td>
 <td style="text-align:left;">
-This is the National Provider Number issued to health care providers in the US by the Centers for Medicare and Medicaid Services (CMS).
+This is the National Provider Number issued to health care providers in
+the US by the Centers for Medicare and Medicaid Services (CMS).
 </td>
 <td style="text-align:left;">
 </td>
@@ -7711,7 +8860,8 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 dea
 </td>
 <td style="text-align:left;">
-This is the identifier issued by the DEA, a US federal agency, that allows a provider to write prescriptions for controlled substances.
+This is the identifier issued by the DEA, a US federal agency, that
+allows a provider to write prescriptions for controlled substances.
 </td>
 <td style="text-align:left;">
 </td>
@@ -7737,10 +8887,20 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 specialty_concept_id
 </td>
 <td style="text-align:left;">
-This field either represents the most common specialty that occurs in the data or the most specific concept that represents all specialties listed, should the provider have more than one. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.
+This field either represents the most common specialty that occurs in
+the data or the most specific concept that represents all specialties
+listed, should the provider have more than one. This includes physician
+specialties such as internal medicine, emergency medicine, etc. and
+allied health professionals such as nurses, midwives, and pharmacists.
 </td>
 <td style="text-align:left;">
-If a Provider has more than one Specialty, there are two options: 1. Choose a concept_id which is a common ancestor to the multiple specialties, or, 2. Choose the specialty that occurs most often for the provider. Concepts in this field should be Standard with a domain of Provider. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Provider&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If a Provider has more than one Specialty, there are two options: 1.
+Choose a concept_id which is a common ancestor to the multiple
+specialties, or, 2. Choose the specialty that occurs most often for the
+provider. Concepts in this field should be Standard with a domain of
+Provider. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Provider&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -7765,10 +8925,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-This is the CARE_SITE_ID for the location that the provider primarily practices in.
+This is the CARE_SITE_ID for the location that the provider primarily
+practices in.
 </td>
 <td style="text-align:left;">
-If a Provider has more than one Care Site, the main or most often exerted CARE_SITE_ID should be recorded.
+If a Provider has more than one Care Site, the main or most often
+exerted CARE_SITE_ID should be recorded.
 </td>
 <td style="text-align:left;">
 integer
@@ -7818,10 +8980,14 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 gender_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the recorded gender of the provider in the source data.
+This field represents the recorded gender of the provider in the source
+data.
 </td>
 <td style="text-align:left;">
-If given, put a concept from the gender domain representing the recorded gender of the provider. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If given, put a concept from the gender domain representing the recorded
+gender of the provider. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -7847,10 +9013,13 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 provider_source_value
 </td>
 <td style="text-align:left;">
-Use this field to link back to providers in the source data. This is typically used for error checking of ETL logic.
+Use this field to link back to providers in the source data. This is
+typically used for error checking of ETL logic.
 </td>
 <td style="text-align:left;">
-Some use cases require the ability to link back to providers in the source data. This field allows for the storing of the provider identifier as it appears in the source.
+Some use cases require the ability to link back to providers in the
+source data. This field allows for the storing of the provider
+identifier as it appears in the source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -7874,10 +9043,15 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 specialty_source_value
 </td>
 <td style="text-align:left;">
-This is the kind of provider or specialty as it appears in the source data. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.
+This is the kind of provider or specialty as it appears in the source
+data. This includes physician specialties such as internal medicine,
+emergency medicine, etc. and allied health professionals such as nurses,
+midwives, and pharmacists.
 </td>
 <td style="text-align:left;">
-Put the kind of provider as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.
+Put the kind of provider as it appears in the source data. This field is
+up to the discretion of the ETL-er as to whether this should be the
+coded value from the source or the text description of the lookup value.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -7901,10 +9075,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 specialty_source_concept_id
 </td>
 <td style="text-align:left;">
-This is often zero as many sites use proprietary codes to store physician speciality.
+This is often zero as many sites use proprietary codes to store
+physician speciality.
 </td>
 <td style="text-align:left;">
-If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here.
+If the source data codes provider specialty in an OMOP supported
+vocabulary store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -7932,7 +9108,9 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 This is provider’s gender as it appears in the source data.
 </td>
 <td style="text-align:left;">
-Put the provider’s gender as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.
+Put the provider’s gender as it appears in the source data. This field
+is up to the discretion of the ETL-er as to whether this should be the
+coded value from the source or the text description of the lookup value.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -7956,10 +9134,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 gender_source_concept_id
 </td>
 <td style="text-align:left;">
-This is often zero as many sites use proprietary codes to store provider gender.
+This is often zero as many sites use proprietary codes to store provider
+gender.
 </td>
 <td style="text-align:left;">
-If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here.
+If the source data codes provider gender in an OMOP supported vocabulary
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -7988,9 +9168,25 @@ <h2><strong>Health Economics Data Tables</strong></h2>
 <div id="payer_plan_period" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <p><strong>Table Description</strong></p>
-<p>The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.</p>
+<p>The PAYER_PLAN_PERIOD table captures details of the period of time
+that a Person is continuously enrolled under a specific health Plan
+benefit structure from a given Payer. Each Person receiving healthcare
+is typically covered by a health benefit plan, which pays for (fully or
+partially), or directly provides, the care. These benefit plans are
+provided by payers, such as health insurances or state or government
+agencies. In each plan the details of the health benefits are defined
+for the Person or her family, and the health benefit Plan might change
+over time typically with increasing utilization (reaching certain cost
+thresholds such as deductibles), plan availability and purchasing
+choices of the Person. The unique combinations of Payer organizations,
+health benefit Plans and time periods in which they are valid for a
+Person are recorded in this table.</p>
 <p><strong>User Guide</strong></p>
-<p>A Person can have multiple, overlapping, Payer_Plan_Periods in this table. For example, medical and drug coverage in the US can be represented by two Payer_Plan_Periods. The details of the benefit structure of the Plan is rarely known, the idea is just to identify that the Plans are different.</p>
+<p>A Person can have multiple, overlapping, Payer_Plan_Periods in this
+table. For example, medical and drug coverage in the US can be
+represented by two Payer_Plan_Periods. The details of the benefit
+structure of the Plan is rarely known, the idea is just to identify that
+the Plans are different.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -8029,7 +9225,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 payer_plan_period_id
 </td>
 <td style="text-align:left;">
-A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time.
+A unique identifier for each unique combination of a Person, Payer,
+Plan, and Period of time.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8058,7 +9255,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 The Person covered by the Plan.
 </td>
 <td style="text-align:left;">
-A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records
+A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD
+records
 </td>
 <td style="text-align:left;">
 integer
@@ -8135,10 +9333,17 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 payer_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the organization who reimburses the provider which administers care to the Person.
+This field represents the organization who reimburses the provider which
+administers care to the Person.
 </td>
 <td style="text-align:left;">
-Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the Payer directly to a standard CONCEPT_ID. If one does not exists
+please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. The point is to stratify on
+this information and identify if Persons have the same payer, though the
+name of the Payer is not necessary. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8191,7 +9396,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the Payer in an OMOP supported vocabulary store
+the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8216,10 +9422,17 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 plan_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the specific health benefit Plan the Person is enrolled in.
+This field represents the specific health benefit Plan the Person is
+enrolled in.
 </td>
 <td style="text-align:left;">
-Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Plan&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the Plan directly to a standard CONCEPT_ID. If one does not exists
+please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. The point is to stratify on
+this information and identify if Persons have the same health benefit
+Plan though the name of the Plan is not necessary. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Plan&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8244,7 +9457,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 plan_source_value
 </td>
 <td style="text-align:left;">
-This is the health benefit Plan of the Person as it appears in the source data.
+This is the health benefit Plan of the Person as it appears in the
+source data.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8272,7 +9486,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the Plan in an OMOP supported vocabulary store
+the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8297,10 +9512,18 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 sponsor_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan.
+This field represents the sponsor of the Plan who finances the Plan.
+This includes self-insured, small group health plan and large group
+health plan.
 </td>
 <td style="text-align:left;">
-Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the sponsor directly to a standard CONCEPT_ID. If one does not
+exists please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. The point is to stratify on
+this information and identify if Persons have the same sponsor though
+the name of the sponsor is not necessary. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8353,7 +9576,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the sponsor in an OMOP supported vocabulary
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8378,10 +9602,12 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 family_source_value
 </td>
 <td style="text-align:left;">
-The common identifier for all people (often a family) that covered by the same policy.
+The common identifier for all people (often a family) that covered by
+the same policy.
 </td>
 <td style="text-align:left;">
-Often these are the common digits of the enrollment id of the policy members.
+Often these are the common digits of the enrollment id of the policy
+members.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8408,7 +9634,11 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 This field represents the reason the Person left the Plan, if known.
 </td>
 <td style="text-align:left;">
-Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the stop reason directly to a standard CONCEPT_ID. If one does not
+exists please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8461,7 +9691,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the stop reason in an OMOP supported vocabulary
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8487,12 +9718,36 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <div id="cost" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">COST</h3>
 <p><strong>Table Description</strong></p>
-<p>The COST table captures records containing the cost of any medical event recorded in one of the OMOP clinical event tables such as DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL, DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT.</p>
-<p>Each record in the cost table account for the amount of money transacted for the clinical event. So, the COST table may be used to represent both receivables (charges) and payments (paid), each transaction type represented by its COST_CONCEPT_ID. The COST_TYPE_CONCEPT_ID field will use concepts in the Standardized Vocabularies to designate the source (provenance) of the cost data. A reference to the health plan information in the PAYER_PLAN_PERIOD table is stored in the record for information used for the adjudication system to determine the persons benefit for the clinical event.</p>
+<p>The COST table captures records containing the cost of any medical
+event recorded in one of the OMOP clinical event tables such as
+DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL,
+DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT.</p>
+<p>Each record in the cost table account for the amount of money
+transacted for the clinical event. So, the COST table may be used to
+represent both receivables (charges) and payments (paid), each
+transaction type represented by its COST_CONCEPT_ID. The
+COST_TYPE_CONCEPT_ID field will use concepts in the Standardized
+Vocabularies to designate the source (provenance) of the cost data. A
+reference to the health plan information in the PAYER_PLAN_PERIOD table
+is stored in the record for information used for the adjudication system
+to determine the persons benefit for the clinical event.</p>
 <p><strong>User Guide</strong></p>
-<p>When dealing with summary costs, the cost of the goods or services the provider provides is often not known directly, but derived from the hospital charges multiplied by an average cost-to-charge ratio.</p>
+<p>When dealing with summary costs, the cost of the goods or services
+the provider provides is often not known directly, but derived from the
+hospital charges multiplied by an average cost-to-charge ratio.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. Therefore, it is possible for one procedure to have multiple cost records for each payer, but typically it contains one or no record per entity. Payer reimbursement cost records will be identified by using the PAYER_PLAN_ID field. Drug costs are composed of ingredient cost (the amount charged by the wholesale distributor or manufacturer), the dispensing fee (the amount charged by the pharmacy and the sales tax).</p>
+<p>One cost record is generated for each response by a payer. In a
+claims databases, the payment and payment terms reported by the payer
+for the goods or services billed will generate one cost record. If the
+source data has payment information for more than one payer
+(i.e. primary insurance and secondary insurance payment for one entity),
+then a cost record is created for each reporting payer. Therefore, it is
+possible for one procedure to have multiple cost records for each payer,
+but typically it contains one or no record per entity. Payer
+reimbursement cost records will be identified by using the PAYER_PLAN_ID
+field. Drug costs are composed of ingredient cost (the amount charged by
+the wholesale distributor or manufacturer), the dispensing fee (the
+amount charged by the pharmacy and the sales tax).</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -9010,7 +10265,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 revenue_code_source_value
 </td>
 <td style="text-align:left;">
-Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system.
+Revenue codes are a method to charge for a class of procedures and
+conditions in the U.S. hospital system.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9062,7 +10318,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 drg_source_value
 </td>
 <td style="text-align:left;">
-Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups.
+Diagnosis Related Groups are US codes used to classify hospital cases
+into one of approximately 500 groups.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9092,9 +10349,15 @@ <h2><strong>Standardized Derived Elements</strong></h2>
 <div id="drug_era" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <p><strong>Table Description</strong></p>
-<p>A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras.</p>
+<p>A Drug Era is defined as a span of time when the Person is assumed to
+be exposed to a particular active ingredient. A Drug Era is not the same
+as a Drug Exposure: Exposures are individual records corresponding to
+the source when Drug was delivered to the Person, while successive
+periods of Drug Exposures are combined under certain rules to produce
+continuous Drug Eras.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>The SQL script for generating DRUG_ERA records can be found <a href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#drug_eras">here</a>.</p>
+<p>The SQL script for generating DRUG_ERA records can be found <a
+href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#drug_eras">here</a>.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -9214,7 +10477,8 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure.
+The Drug Era Start Date is the start date of the first Drug Exposure for
+a given ingredient, with at least 31 days since the previous exposure.
 </td>
 <td style="text-align:left;">
 date
@@ -9240,7 +10504,19 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules: For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information. For Procedure Drugs, usually the drug is administered on a single date (i.e., the administration date). A standard Persistence Window of 30 days (gap, slack) is permitted between two subsequent such extrapolated DRUG_EXPOSURE records to be considered to be merged into a single Drug Era.
+The Drug Era End Date is the end date of the last Drug Exposure. The End
+Date of each Drug Exposure is either taken from the field
+drug_exposure_end_date or, as it is typically not available, inferred
+using the following rules: For pharmacy prescription data, the date when
+the drug was dispensed plus the number of days of supply are used to
+extrapolate the End Date for the Drug Exposure. Depending on the
+country-specific healthcare system, this supply information is either
+explicitly provided in the day_supply field or inferred from package
+size or similar information. For Procedure Drugs, usually the drug is
+administered on a single date (i.e., the administration date). A
+standard Persistence Window of 30 days (gap, slack) is permitted between
+two subsequent such extrapolated DRUG_EXPOSURE records to be considered
+to be merged into a single Drug Era.
 </td>
 <td style="text-align:left;">
 date
@@ -9291,7 +10567,16 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The Gap Days determine how many total drug-free days are observed between all Drug Exposure events that contribute to a DRUG_ERA record. It is assumed that the drugs are “not stockpiled” by the patient, i.e. that if a new drug prescription or refill is observed (a new DRUG_EXPOSURE record is written), the remaining supply from the previous events is abandoned. The difference between Persistence Window and Gap Days is that the former is the maximum drug-free time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual drug-free days for the given Drug Era under the above assumption of non-stockpiling.
+The Gap Days determine how many total drug-free days are observed
+between all Drug Exposure events that contribute to a DRUG_ERA record.
+It is assumed that the drugs are “not stockpiled” by the patient,
+i.e. that if a new drug prescription or refill is observed (a new
+DRUG_EXPOSURE record is written), the remaining supply from the previous
+events is abandoned. The difference between Persistence Window and Gap
+Days is that the former is the maximum drug-free time allowed between
+two subsequent DRUG_EXPOSURE records, while the latter is the sum of
+actual drug-free days for the given Drug Era under the above assumption
+of non-stockpiling.
 </td>
 <td style="text-align:left;">
 integer
@@ -9316,9 +10601,15 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <div id="dose_era" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 <p><strong>Table Description</strong></p>
-<p>A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.</p>
+<p>A Dose Era is defined as a span of time when the Person is assumed to
+be exposed to a constant dose of a specific active ingredient.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Dose Eras will be derived from records in the DRUG_EXPOSURE table and the Dose information from the DRUG_STRENGTH table using a standardized algorithm. Dose Form information is not taken into account. So, if the patient changes between different formulations, or different manufacturers with the same formulation, the Dose Era is still spanning the entire time of exposure to the Ingredient.</p>
+<p>Dose Eras will be derived from records in the DRUG_EXPOSURE table and
+the Dose information from the DRUG_STRENGTH table using a standardized
+algorithm. Dose Form information is not taken into account. So, if the
+patient changes between different formulations, or different
+manufacturers with the same formulation, the Dose Era is still spanning
+the entire time of exposure to the Ingredient.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -9490,7 +10781,8 @@ <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 dose_era_start_date
 </td>
 <td style="text-align:left;">
-The date the Person started on the specific dosage, with at least 31 days since any prior exposure.
+The date the Person started on the specific dosage, with at least 31
+days since any prior exposure.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9518,7 +10810,9 @@ <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The date the Person was no longer exposed to the dosage of the specific drug ingredient. An era is ended if there are 31 days or more between dosage records.
+The date the Person was no longer exposed to the dosage of the specific
+drug ingredient. An era is ended if there are 31 days or more between
+dosage records.
 </td>
 <td style="text-align:left;">
 date
@@ -9543,13 +10837,39 @@ <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 <div id="condition_era" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 <p><strong>Table Description</strong></p>
-<p>A Condition Era is defined as a span of time when the Person is assumed to have a given condition. Similar to Drug Eras, Condition Eras are chronological periods of Condition Occurrence. Combining individual Condition Occurrences into a single Condition Era serves two purposes:</p>
+<p>A Condition Era is defined as a span of time when the Person is
+assumed to have a given condition. Similar to Drug Eras, Condition Eras
+are chronological periods of Condition Occurrence. Combining individual
+Condition Occurrences into a single Condition Era serves two
+purposes:</p>
 <ul>
-<li>It allows aggregation of chronic conditions that require frequent ongoing care, instead of treating each Condition Occurrence as an independent event.</li>
-<li>It allows aggregation of multiple, closely timed doctor visits for the same Condition to avoid double-counting the Condition Occurrences. For example, consider a Person who visits her Primary Care Physician (PCP) and who is referred to a specialist. At a later time, the Person visits the specialist, who confirms the PCP’s original diagnosis and provides the appropriate treatment to resolve the condition. These two independent doctor visits should be aggregated into one Condition Era.</li>
+<li>It allows aggregation of chronic conditions that require frequent
+ongoing care, instead of treating each Condition Occurrence as an
+independent event.</li>
+<li>It allows aggregation of multiple, closely timed doctor visits for
+the same Condition to avoid double-counting the Condition Occurrences.
+For example, consider a Person who visits her Primary Care Physician
+(PCP) and who is referred to a specialist. At a later time, the Person
+visits the specialist, who confirms the PCP’s original diagnosis and
+provides the appropriate treatment to resolve the condition. These two
+independent doctor visits should be aggregated into one Condition
+Era.</li>
 </ul>
 <p><strong>ETL Conventions</strong></p>
-<p>Each Condition Era corresponds to one or many Condition Occurrence records that form a continuous interval. The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers. The SQl Script for generating CONDITION_ERA records can be found <a href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#condition_eras">here</a> The Condition Era Start Date is the start date of the first Condition Occurrence. The Condition Era End Date is the end date of the last Condition Occurrence. Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurrence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date.</p>
+<p>Each Condition Era corresponds to one or many Condition Occurrence
+records that form a continuous interval. The condition_concept_id field
+contains Concepts that are identical to those of the
+CONDITION_OCCURRENCE table records that make up the Condition Era. In
+contrast to Drug Eras, Condition Eras are not aggregated to contain
+Conditions of different hierarchical layers. The SQl Script for
+generating CONDITION_ERA records can be found <a
+href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#condition_eras">here</a>
+The Condition Era Start Date is the start date of the first Condition
+Occurrence. The Condition Era End Date is the end date of the last
+Condition Occurrence. Condition Eras are built with a Persistence Window
+of 30 days, meaning, if no occurrence of the same condition_concept_id
+happens within 30 days of any one occurrence, it will be considered the
+condition_era_end_date.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -9667,7 +10987,10 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 condition_era_start_date
 </td>
 <td style="text-align:left;">
-The start date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the start date of the very first chronologically recorded instance of the condition with at least 31 days since any prior record of the same Condition.
+The start date for the Condition Era constructed from the individual
+instances of Condition Occurrences. It is the start date of the very
+first chronologically recorded instance of the condition with at least
+31 days since any prior record of the same Condition.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9693,7 +11016,9 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 condition_era_end_date
 </td>
 <td style="text-align:left;">
-The end date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the end date of the final continuously recorded instance of the Condition.
+The end date for the Condition Era constructed from the individual
+instances of Condition Occurrences. It is the end date of the final
+continuously recorded instance of the Condition.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9719,7 +11044,8 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 condition_occurrence_count
 </td>
 <td style="text-align:left;">
-The number of individual Condition Occurrences used to construct the condition era.
+The number of individual Condition Occurrences used to construct the
+condition era.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9749,7 +11075,8 @@ <h2><strong>Metadata Tables</strong></h2>
 <div id="metadata" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">METADATA</h3>
 <p><strong>Table Description</strong></p>
-<p>The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.</p>
+<p>The METADATA table contains metadata information about a dataset that
+has been transformed to the OMOP Common Data Model.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -9967,7 +11294,9 @@ <h3 class="tabset tabset-pills">METADATA</h3>
 <div id="cdm_source" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CDM_SOURCE</h3>
 <p><strong>Table Description</strong></p>
-<p>The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.</p>
+<p>The CDM_SOURCE table contains detail about the source database and
+the process used to transform the data into the OMOP Common Data
+Model.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10267,9 +11596,26 @@ <h2><strong>Vocabulary Tables</strong></h2>
 <div id="concept" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT</h3>
 <p><strong>Table Description</strong></p>
-<p>The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and within standardized analytics. Each Standard Concept belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.</p>
-<p>Concepts can represent broad categories (like ‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’) or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.).</p>
-<p>Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom Concepts defined to cover various aspects of observational data analysis.</p>
+<p>The Standardized Vocabularies contains records, or Concepts, that
+uniquely identify each fundamental unit of meaning used to express
+clinical information in all domain tables of the CDM. Concepts are
+derived from vocabularies, which represent clinical information across a
+domain (e.g. conditions, drugs, procedures) through the use of codes and
+associated descriptions. Some Concepts are designated Standard Concepts,
+meaning these Concepts can be used as normative expressions of a
+clinical entity within the OMOP Common Data Model and within
+standardized analytics. Each Standard Concept belongs to one domain,
+which defines the location where the Concept would be expected to occur
+within data tables of the CDM.</p>
+<p>Concepts can represent broad categories (like ‘Cardiovascular
+disease’), detailed clinical elements (‘Myocardial infarction of the
+anterolateral wall’) or modifying characteristics and attributes that
+define Concepts at various levels of detail (severity of a disease,
+associated morphology, etc.).</p>
+<p>Records in the Standardized Vocabularies tables are derived from
+national or international vocabularies such as SNOMED-CT, RxNorm, and
+LOINC, or custom Concepts defined to cover various aspects of
+observational data analysis.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10360,7 +11706,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 domain_id
 </td>
 <td style="text-align:left;">
-A foreign key to the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#domain">DOMAIN</a> table the Concept belongs to.
+A foreign key to the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#domain">DOMAIN</a>
+table the Concept belongs to.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10387,7 +11735,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 vocabulary_id
 </td>
 <td style="text-align:left;">
-A foreign key to the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#vocabulary">VOCABULARY</a> table indicating from which source the Concept has been adapted.
+A foreign key to the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#vocabulary">VOCABULARY</a>
+table indicating from which source the Concept has been adapted.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10414,7 +11764,8 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 concept_class_id
 </td>
 <td style="text-align:left;">
-The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc.
+The attribute or concept class of the Concept. Examples are ‘Clinical
+Drug’, ‘Ingredient’, ‘Clinical Finding’ etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10441,7 +11792,10 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 standard_concept
 </td>
 <td style="text-align:left;">
-This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL.
+This flag determines where a Concept is a Standard Concept, i.e. is used
+in the data, a Classification Concept, or a non-standard Source Concept.
+The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification
+Concept), otherwise the content is NULL.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10467,7 +11821,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 concept_code
 </td>
 <td style="text-align:left;">
-The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies.
+The concept code represents the identifier of the Concept in the source
+vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that
+concept codes are not unique across vocabularies.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10493,7 +11849,8 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 valid_start_date
 </td>
 <td style="text-align:left;">
-The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning, the Concept has no (known) date of inception.
+The date when the Concept was first recorded. The default value is
+1-Jan-1970, meaning, the Concept has no (known) date of inception.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10519,7 +11876,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 valid_end_date
 </td>
 <td style="text-align:left;">
-The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning, the Concept is valid until it becomes deprecated.
+The date when the Concept became invalid because it was deleted or
+superseded (updated) by a new concept. The default value is 31-Dec-2099,
+meaning, the Concept is valid until it becomes deprecated.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10545,7 +11904,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-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.
+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.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10572,7 +11933,11 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 <div id="vocabulary" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">VOCABULARY</h3>
 <p><strong>Table Description</strong></p>
-<p>The VOCABULARY table includes a list of the Vocabularies collected from various sources or created de novo by the OMOP community. This reference table is populated with a single record for each Vocabulary source and includes a descriptive name and other associated attributes for the Vocabulary.</p>
+<p>The VOCABULARY table includes a list of the Vocabularies collected
+from various sources or created de novo by the OMOP community. This
+reference table is populated with a single record for each Vocabulary
+source and includes a descriptive name and other associated attributes
+for the Vocabulary.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10637,7 +12002,9 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 vocabulary_name
 </td>
 <td style="text-align:left;">
-The name describing the vocabulary, for example, International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS) etc.
+The name describing the vocabulary, for example, International
+Classification of Diseases, Ninth Revision, Clinical Modification,
+Volume 1 and 2 (NCHS) etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10663,7 +12030,8 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 vocabulary_reference
 </td>
 <td style="text-align:left;">
-External reference to documentation or available download of the about the vocabulary.
+External reference to documentation or available download of the about
+the vocabulary.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10715,7 +12083,8 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 vocabulary_concept_id
 </td>
 <td style="text-align:left;">
-A Concept that represents the Vocabulary the VOCABULARY record belongs to.
+A Concept that represents the Vocabulary the VOCABULARY record belongs
+to.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10743,7 +12112,14 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 <div id="domain" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DOMAIN</h3>
 <p><strong>Table Description</strong></p>
-<p>The DOMAIN table includes a list of OMOP-defined Domains the Concepts of the Standardized Vocabularies can belong to. A Domain defines the set of allowable Concepts for the standardized fields in the CDM tables. For example, the “Condition” Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.</p>
+<p>The DOMAIN table includes a list of OMOP-defined Domains the Concepts
+of the Standardized Vocabularies can belong to. A Domain defines the set
+of allowable Concepts for the standardized fields in the CDM tables. For
+example, the “Condition” Domain contains Concepts that describe a
+condition of a patient, and these Concepts can only be stored in the
+condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA
+tables. This reference table is populated with a single record for each
+Domain and includes a descriptive name for the Domain.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10808,7 +12184,8 @@ <h3 class="tabset tabset-pills">DOMAIN</h3>
 domain_name
 </td>
 <td style="text-align:left;">
-The name describing the Domain, e.g. Condition, Procedure, Measurement etc.
+The name describing the Domain, e.g. Condition, Procedure, Measurement
+etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10862,7 +12239,10 @@ <h3 class="tabset tabset-pills">DOMAIN</h3>
 <div id="concept_class" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_CLASS</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_CLASS table is a reference table, which includes a list of the classifications used to differentiate Concepts within a given Vocabulary. This reference table is populated with a single record for each Concept Class.</p>
+<p>The CONCEPT_CLASS table is a reference table, which includes a list
+of the classifications used to differentiate Concepts within a given
+Vocabulary. This reference table is populated with a single record for
+each Concept Class.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10927,7 +12307,8 @@ <h3 class="tabset tabset-pills">CONCEPT_CLASS</h3>
 concept_class_name
 </td>
 <td style="text-align:left;">
-The name describing the Concept Class, e.g. Clinical Finding, Ingredient, etc.
+The name describing the Concept Class, e.g. Clinical Finding,
+Ingredient, etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10978,10 +12359,14 @@ <h3 class="tabset tabset-pills">CONCEPT_CLASS</h3>
 </tbody>
 </table>
 </div>
-<div id="concept_relationship" class="section level3 tabset tabset-pills">
+<div id="concept_relationship"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the RELATIONSHIP table.</p>
+<p>The CONCEPT_RELATIONSHIP table contains records that define direct
+relationships between any two Concepts and the nature or type of the
+relationship. Each type of a relationship is defined in the RELATIONSHIP
+table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11072,7 +12457,10 @@ <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 relationship_id
 </td>
 <td style="text-align:left;">
-The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the <a href="https://ohdsi.github.io/CommonDataModel/dataModelConventions.html#concept_relationships">Vocabulary Conventions</a>. for more information.
+The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the
+<a
+href="https://ohdsi.github.io/CommonDataModel/dataModelConventions.html#concept_relationships">Vocabulary
+Conventions</a>. for more information.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11151,7 +12539,8 @@ <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-Reason the relationship was invalidated. Possible values are ‘D’ (deleted), ‘U’ (updated) or NULL.
+Reason the relationship was invalidated. Possible values are ‘D’
+(deleted), ‘U’ (updated) or NULL.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11178,7 +12567,9 @@ <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 <div id="relationship" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 <p><strong>Table Description</strong></p>
-<p>The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.</p>
+<p>The RELATIONSHIP table provides a reference list of all types of
+relationships that can be used to associate any two concepts in the
+CONCEPT_RELATIONSHP table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11268,7 +12659,8 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 is_hierarchical
 </td>
 <td style="text-align:left;">
-Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not.
+Defines whether a relationship defines concepts into classes or
+hierarchies. Values are 1 for hierarchical relationship or 0 if not.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11294,7 +12686,9 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 defines_ancestry
 </td>
 <td style="text-align:left;">
-Defines whether a hierarchical relationship contributes to the concept_ancestor table. These are subsets of the hierarchical relationships. Valid values are 1 or 0.
+Defines whether a hierarchical relationship contributes to the
+concept_ancestor table. These are subsets of the hierarchical
+relationships. Valid values are 1 or 0.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11320,7 +12714,8 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 reverse_relationship_id
 </td>
 <td style="text-align:left;">
-The identifier for the relationship used to define the reverse relationship between two concepts.
+The identifier for the relationship used to define the reverse
+relationship between two concepts.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11346,7 +12741,9 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 relationship_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key that refers to an identifier in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept">CONCEPT</a> table for the unique relationship concept.
+A foreign key that refers to an identifier in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept">CONCEPT</a>
+table for the unique relationship concept.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11374,7 +12771,8 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 <div id="concept_synonym" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_SYNONYM</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.</p>
+<p>The CONCEPT_SYNONYM table is used to store alternate names and
+descriptions for Concepts.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11491,8 +12889,19 @@ <h3 class="tabset tabset-pills">CONCEPT_SYNONYM</h3>
 <div id="concept_ancestor" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.</p>
-<p>This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.</p>
+<p>The CONCEPT_ANCESTOR table is designed to simplify observational
+analysis by providing the complete hierarchical relationships between
+Concepts. Only direct parent-child relationships between Concepts are
+stored in the CONCEPT_RELATIONSHIP table. To determine higher level
+ancestry connections, all individual direct relationships would have to
+be navigated at analysis time. The CONCEPT_ANCESTOR table includes
+records for all parent-child relationships, as well as
+grandparent-grandchild relationships and those of any other level of
+lineage. Using the CONCEPT_ANCESTOR table allows for querying for all
+descendants of a hierarchical concept. For example, drug ingredients and
+drug products are all descendants of a drug class ancestor.</p>
+<p>This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP
+and RELATIONSHIP tables.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11531,7 +12940,8 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 ancestor_concept_id
 </td>
 <td style="text-align:left;">
-The Concept Id for the higher-level concept that forms the ancestor in the relationship.
+The Concept Id for the higher-level concept that forms the ancestor in
+the relationship.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11558,7 +12968,8 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 descendant_concept_id
 </td>
 <td style="text-align:left;">
-The Concept Id for the lower-level concept that forms the descendant in the relationship.
+The Concept Id for the lower-level concept that forms the descendant in
+the relationship.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11585,7 +12996,9 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 min_levels_of_separation
 </td>
 <td style="text-align:left;">
-The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.
+The minimum separation in number of levels of hierarchy between ancestor
+and descendant concepts. This is an attribute that is used to simplify
+hierarchic analysis.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11611,7 +13024,9 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 max_levels_of_separation
 </td>
 <td style="text-align:left;">
-The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.
+The maximum separation in number of levels of hierarchy between ancestor
+and descendant concepts. This is an attribute that is used to simplify
+hierarchic analysis.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11635,10 +13050,18 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 </tbody>
 </table>
 </div>
-<div id="source_to_concept_map" class="section level3 tabset tabset-pills">
+<div id="source_to_concept_map"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 <p><strong>Table Description</strong></p>
-<p>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.</p>
+<p>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.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11703,10 +13126,12 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 source_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key to the Source Concept that is being translated into a Standard Concept.
+A foreign key to the Source Concept that is being translated into a
+Standard Concept.
 </td>
 <td style="text-align:left;">
-This is either 0 or should be a number above 2 billion, which are the Concepts reserved for site-specific codes and mappings.
+This is either 0 or should be a number above 2 billion, which are the
+Concepts reserved for site-specific codes and mappings.
 </td>
 <td style="text-align:left;">
 integer
@@ -11731,7 +13156,8 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 source_vocabulary_id
 </td>
 <td style="text-align:left;">
-A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept.
+A foreign key to the VOCABULARY table defining the vocabulary of the
+source code that is being translated to a Standard Concept.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11757,7 +13183,9 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 source_code_description
 </td>
 <td style="text-align:left;">
-An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept.
+An optional description for the source code. This is included as a
+convenience to compare the description of the source code to the name of
+the concept.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11863,7 +13291,9 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 valid_end_date
 </td>
 <td style="text-align:left;">
-The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. Default value is 31-Dec-2099.
+The date when the mapping instance became invalid because it was deleted
+or superseded (updated) by a new relationship. Default value is
+31-Dec-2099.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11889,7 +13319,9 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value.
+Reason the mapping instance was invalidated. Possible values are D
+(deleted), U (replaced with an update) or NULL when valid_end_date has
+the default value.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11916,7 +13348,10 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 <div id="drug_strength" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 <p><strong>Table Description</strong></p>
-<p>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.</p>
+<p>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.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11982,10 +13417,12 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 ingredient_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the active ingredient contained within the drug product.
+The Concept representing the active ingredient contained within the drug
+product.
 </td>
 <td style="text-align:left;">
-Combination Drugs will have more than one record in this table, one for each active Ingredient.
+Combination Drugs will have more than one record in this table, one for
+each active Ingredient.
 </td>
 <td style="text-align:left;">
 integer
@@ -12010,7 +13447,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 amount_value
 </td>
 <td style="text-align:left;">
-The numeric value or the amount of active ingredient contained within the drug product.
+The numeric value or the amount of active ingredient contained within
+the drug product.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12036,7 +13474,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 amount_unit_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the Unit of measure for the amount of active ingredient contained within the drug product.
+The Concept representing the Unit of measure for the amount of active
+ingredient contained within the drug product.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12063,7 +13502,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 numerator_value
 </td>
 <td style="text-align:left;">
-The concentration of the active ingredient contained within the drug product.
+The concentration of the active ingredient contained within the drug
+product.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12089,7 +13529,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 numerator_unit_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the Unit of measure for the concentration of active ingredient.
+The Concept representing the Unit of measure for the concentration of
+active ingredient.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12116,7 +13557,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 denominator_value
 </td>
 <td style="text-align:left;">
-The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.).
+The amount of total liquid (or other divisible product, such as
+ointment, gel, spray, etc.).
 </td>
 <td style="text-align:left;">
 </td>
@@ -12142,7 +13584,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 denominator_unit_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the denominator unit for the concentration of active ingredient.
+The Concept representing the denominator unit for the concentration of
+active ingredient.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12169,7 +13612,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 box_size
 </td>
 <td style="text-align:left;">
-The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient.
+The number of units of Clinical Branded Drug or Quantified Clinical or
+Branded Drug contained in a box as dispensed to the patient.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12195,7 +13639,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 valid_start_date
 </td>
 <td style="text-align:left;">
-The date when the Concept was first recorded. The default value is 1-Jan-1970.
+The date when the Concept was first recorded. The default value is
+1-Jan-1970.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12247,7 +13692,9 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-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.
+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.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12274,7 +13721,15 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 <div id="cohort_definition" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 <p><strong>Table Description</strong></p>
-<p>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.</p>
+<p>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.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12313,7 +13768,8 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 cohort_definition_id
 </td>
 <td style="text-align:left;">
-This is the identifier given to the cohort, usually by the ATLAS application
+This is the identifier given to the cohort, usually by the ATLAS
+application
 </td>
 <td style="text-align:left;">
 </td>
@@ -12391,7 +13847,8 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 definition_type_concept_id
 </td>
 <td style="text-align:left;">
-Type defining what kind of Cohort Definition the record represents and how the syntax may be executed.
+Type defining what kind of Cohort Definition the record represents and
+how the syntax may be executed.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12444,7 +13901,8 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 subject_concept_id
 </td>
 <td style="text-align:left;">
-This field contains a Concept that represents the domain of the subjects that are members of the cohort (e.g., Person, Provider, Visit).
+This field contains a Concept that represents the domain of the subjects
+that are members of the cohort (e.g., Person, Provider, Visit).
 </td>
 <td style="text-align:left;">
 </td>
@@ -12495,10 +13953,18 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 </tbody>
 </table>
 </div>
-<div id="attribute_definition" class="section level3 tabset tabset-pills">
+<div id="attribute_definition"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">ATTRIBUTE_DEFINITION</h3>
 <p><strong>Table Description</strong></p>
-<p>The ATTRIBUTE_DEFINITION table contains records to define each attribute through an associated description and syntax. Attributes are derived elements that can be selected or calculated for a subject within a cohort. The ATTRIBUTE_DEFINITION table provides a standardized structure for maintaining the rules governing the calculation of covariates for a subject in a cohort, and can store operational programming code to instantiate the attributes for a given cohort within the OMOP Common Data Model.</p>
+<p>The ATTRIBUTE_DEFINITION table contains records to define each
+attribute through an associated description and syntax. Attributes are
+derived elements that can be selected or calculated for a subject within
+a cohort. The ATTRIBUTE_DEFINITION table provides a standardized
+structure for maintaining the rules governing the calculation of
+covariates for a subject in a cohort, and can store operational
+programming code to instantiate the attributes for a given cohort within
+the OMOP Common Data Model.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
diff --git a/docs/cdm531.html b/docs/cdm531.html
index 5f572367..d747f33b 100644
--- a/docs/cdm531.html
+++ b/docs/cdm531.html
@@ -13,7 +13,7 @@
 
 <title>OMOP CDM v5.3.1</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -492,7 +496,15 @@ <h1 class="title toc-ignore"><strong>OMOP CDM v5.3.1</strong></h1>
 </div>
 
 
-<p><strong>This documentation previously referenced v5.3.1. During the OHDSI/CommonDataModel Hack-A-Thon that occurred on August 18, 2021 the decision was made to align documentation with the minor releases. This is because only major and minor releases include changes to the model itself while bug fixes address issues with SQL incompatibility, problems in the code, etc. Hot fixes and minor.micro release can be found through the searching of tags. For the CDM v5.3 specification please see the <a href="https://ohdsi.github.io/CommonDataModel/cdm53.html">5.3 page</a>.</strong></p>
+<p><strong>This documentation previously referenced v5.3.1. During the
+OHDSI/CommonDataModel Hack-A-Thon that occurred on August 18, 2021 the
+decision was made to align documentation with the minor releases. This
+is because only major and minor releases include changes to the model
+itself while bug fixes address issues with SQL incompatibility, problems
+in the code, etc. Hot fixes and minor.micro release can be found through
+the searching of tags. For the CDM v5.3 specification please see the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm53.html">5.3
+page</a>.</strong></p>
 
 
 
diff --git a/docs/cdm54.html b/docs/cdm54.html
index 41fde3b9..8eb09d4c 100644
--- a/docs/cdm54.html
+++ b/docs/cdm54.html
@@ -13,7 +13,7 @@
 
 <title>OMOP CDM v5.4</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -492,10 +496,27 @@ <h1 class="title toc-ignore"><strong>OMOP CDM v5.4</strong></h1>
 </div>
 
 
-<p>This is the specification document for the OMOP Common Data Model, v5.4. <strong>This is the latest version of the OMOP CDM.</strong> Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the <a href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a> page.</p>
+<p>This is the specification document for the OMOP Common Data Model,
+v5.4. <strong>This is the latest version of the OMOP CDM.</strong> Each
+table is represented with a high-level description and ETL conventions
+that should be followed. This is continued with a discussion of each
+field in each table, any conventions related to the field, and
+constraints that should be followed (like primary key, foreign key,
+etc). Should you have questions please feel free to visit the <a
+href="https://forums.ohdsi.org/">forums</a> or the <a
+href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a>
+page.</p>
 <div id="current-support-for-cdm-v5.4" class="section level3">
 <h3>Current Support for CDM v5.4</h3>
-<p>The table below details which OHDSI tools support CDM v5.4. There are two levels of support: legacy support means that the tool supports all tables and fields that were present in CDM v5.3 and feature support indicates that the tool supports any new tables and fields in CDM v5.4 that were not present in CDM v5.3. A green check ✅ indicates that the support level for the listed tool is in place, has been tested, and released. A warning sign ⚠️ indicates that the support level for the listed tool has been initiated but has not yet been tested and released. <br></p>
+<p>The table below details which OHDSI tools support CDM v5.4. There are
+two levels of support: legacy support means that the tool supports all
+tables and fields that were present in CDM v5.3 and feature support
+indicates that the tool supports any new tables and fields in CDM v5.4
+that were not present in CDM v5.3. A green check ✅ indicates that the
+support level for the listed tool is in place, has been tested, and
+released. A warning sign ⚠️ indicates that the support level for the
+listed tool has been initiated but has not yet been tested and released.
+<br></p>
 <table>
 <colgroup>
 <col width="25%" />
@@ -514,68 +535,107 @@ <h3>Current Support for CDM v5.4</h3>
 <tbody>
 <tr class="odd">
 <td><strong>CDM R package</strong></td>
-<td>This package can be downloaded from <a href="https://github.com/OHDSI/CommonDataModel/">https://github.com/OHDSI/CommonDataModel/</a>. It functions to dynamically create the OMOP CDM documentation and DDL scripts to instantiate the CDM tables.</td>
+<td>This package can be downloaded from <a
+href="https://github.com/OHDSI/CommonDataModel/">https://github.com/OHDSI/CommonDataModel/</a>.
+It functions to dynamically create the OMOP CDM documentation and DDL
+scripts to instantiate the CDM tables.</td>
 <td>✅</td>
 <td>✅</td>
 </tr>
 <tr class="even">
 <td><strong>Data Quality Dashboard</strong></td>
-<td>This package can be downloaded from <a href="https://github.com/OHDSI/DataQualityDashboard">https://github.com/OHDSI/DataQualityDashboard</a>. It runs a set of &gt; 3500 data quality checks against an OMOP CDM instance and is required to be run on all databases prior to participating in an OHDSI network research study.</td>
+<td>This package can be downloaded from <a
+href="https://github.com/OHDSI/DataQualityDashboard">https://github.com/OHDSI/DataQualityDashboard</a>.
+It runs a set of &gt; 3500 data quality checks against an OMOP CDM
+instance and is required to be run on all databases prior to
+participating in an OHDSI network research study.</td>
 <td>✅</td>
 <td>⚠️</td>
 </tr>
 <tr class="odd">
 <td><strong>Achilles</strong></td>
-<td>This package can be downloaded from <a href="https://github.com/OHDSI/Achilles">https://github.com/OHDSI/Achilles</a>, performing a set of broad database characterizations agains an OMOP CDM instance.</td>
+<td>This package can be downloaded from <a
+href="https://github.com/OHDSI/Achilles">https://github.com/OHDSI/Achilles</a>,
+performing a set of broad database characterizations agains an OMOP CDM
+instance.</td>
 <td>✅</td>
 <td>⚠️</td>
 </tr>
 <tr class="even">
 <td><strong>ARES</strong></td>
-<td>This package can be downloaded from <a href="https://github.com/OHDSI/Ares">https://github.com/OHDSI/Ares</a> and is designed to display the results from both the ACHILLES and DataQualityDashboard packages to support data quality and characterization research.</td>
+<td>This package can be downloaded from <a
+href="https://github.com/OHDSI/Ares">https://github.com/OHDSI/Ares</a>
+and is designed to display the results from both the ACHILLES and
+DataQualityDashboard packages to support data quality and
+characterization research.</td>
 <td>✅</td>
 <td>⚠️</td>
 </tr>
 <tr class="odd">
 <td><strong>ATLAS</strong></td>
-<td>ATLAS is an open source software tool for researchers to conduct scientific analyses on standardized observational data. <a href="http://atlas-demo.ohdsi.org/">Demo</a></td>
+<td>ATLAS is an open source software tool for researchers to conduct
+scientific analyses on standardized observational data. <a
+href="http://atlas-demo.ohdsi.org/">Demo</a></td>
 <td>✅</td>
 <td>⚠️</td>
 </tr>
 <tr class="even">
 <td><strong>Rabbit-In-A-Hat</strong></td>
-<td>This package can be downloaded from <a href="https://github.com/OHDSI/WhiteRabbit">https://github.com/OHDSI/WhiteRabbit</a> and is 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.</td>
+<td>This package can be downloaded from <a
+href="https://github.com/OHDSI/WhiteRabbit">https://github.com/OHDSI/WhiteRabbit</a>
+and is 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.</td>
 <td>✅</td>
 <td>✅</td>
 </tr>
 <tr class="odd">
 <td><strong>Feature Extraction</strong></td>
-<td>This package can be downloaded from <a href="https://github.com/OHDSI/FeatureExtraction">https://github.com/OHDSI/FeatureExtraction</a>. It is designed to generate features (covariates) for a cohort generated using the OMOP CDM.</td>
+<td>This package can be downloaded from <a
+href="https://github.com/OHDSI/FeatureExtraction">https://github.com/OHDSI/FeatureExtraction</a>.
+It is designed to generate features (covariates) for a cohort generated
+using the OMOP CDM.</td>
 <td>✅</td>
 <td>✅*</td>
 </tr>
 <tr class="even">
 <td><strong>Cohort Diagnostics</strong></td>
-<td>This package can be downloaded from <a href="https://github.com/OHDSI/CohortDiagnostics">https://github.com/OHDSI/CohortDiagnostics</a> and is used to critically evaluate cohort phenotypes.</td>
+<td>This package can be downloaded from <a
+href="https://github.com/OHDSI/CohortDiagnostics">https://github.com/OHDSI/CohortDiagnostics</a>
+and is used to critically evaluate cohort phenotypes.</td>
 <td>✅</td>
 <td>⚠️</td>
 </tr>
 </tbody>
 </table>
-<p><br> * The <strong>Feature Extraction</strong> package supports all relevant new features in CDM v5.4. For example, it was decided that, from a methodological perspective, the EPISODE and EPISODE_EVENT tables should not be included to define cohort covariates because the events that make up episodes are already pulled in as potential covariates.</p>
+<p><br> * The <strong>Feature Extraction</strong> package supports all
+relevant new features in CDM v5.4. For example, it was decided that,
+from a methodological perspective, the EPISODE and EPISODE_EVENT tables
+should not be included to define cohort covariates because the events
+that make up episodes are already pulled in as potential covariates.</p>
 <p><br></p>
-<p>Looking to send us a pull request for a bug fix? Please see the <a href="https://github.com/OHDSI/CommonDataModel#readme">readme</a> on the main github page.</p>
+<p>Looking to send us a pull request for a bug fix? Please see the <a
+href="https://github.com/OHDSI/CommonDataModel#readme">readme</a> on the
+main github page.</p>
 </div>
 <div id="clinical-data-tables" class="section level2">
 <h2><strong>Clinical Data Tables</strong></h2>
 <div id="person" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PERSON</h3>
 <p><strong>Table Description</strong></p>
-<p>This table serves as the central identity management for all Persons in the database. It contains records that uniquely identify each person or patient, and some demographic information.</p>
+<p>This table serves as the central identity management for all Persons
+in the database. It contains records that uniquely identify each person
+or patient, and some demographic information.</p>
 <p><strong>User Guide</strong></p>
 <p>All records in this table are independent Persons.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>All Persons in a database needs one record in this table, unless they fail data quality requirements specified in the ETL. Persons with no Events should have a record nonetheless. If more than one data source contributes Events to the database, Persons must be reconciled, if possible, across the sources to create one single record per Person. The content of the BIRTH_DATETIME must be equivalent to the content of BIRTH_DAY, BIRTH_MONTH and BIRTH_YEAR.</p>
+<p>All Persons in a database needs one record in this table, unless they
+fail data quality requirements specified in the ETL. Persons with no
+Events should have a record nonetheless. If more than one data source
+contributes Events to the database, Persons must be reconciled, if
+possible, across the sources to create one single record per Person. The
+content of the BIRTH_DATETIME must be equivalent to the content of
+BIRTH_DAY, BIRTH_MONTH and BIRTH_YEAR.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -614,10 +674,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 person_id
 </td>
 <td style="text-align:left;">
-It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently.
+It is assumed that every person with a different unique identifier is in
+fact a different person and should be treated independently.
 </td>
 <td style="text-align:left;">
-Any person linkage that needs to occur to uniquely identify Persons ought to be done prior to writing this table. This identifier can be the original id from the source data provided if it is an integer, otherwise it can be an autogenerated number.
+Any person linkage that needs to occur to uniquely identify Persons
+ought to be done prior to writing this table. This identifier can be the
+original id from the source data provided if it is an integer, otherwise
+it can be an autogenerated number.
 </td>
 <td style="text-align:left;">
 integer
@@ -641,10 +705,17 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 gender_concept_id
 </td>
 <td style="text-align:left;">
-This field is meant to capture the biological sex at birth of the Person. This field should not be used to study gender identity issues.
+This field is meant to capture the biological sex at birth of the
+Person. This field should not be used to study gender identity issues.
 </td>
 <td style="text-align:left;">
-Use the gender or sex value present in the data under the assumption that it is the biological sex at birth. If the source data captures gender identity it should be stored in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted gender concepts</a>
+Use the gender or sex value present in the data under the assumption
+that it is the biological sex at birth. If the source data captures
+gender identity it should be stored in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a>
+table. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+gender concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -673,7 +744,10 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Compute age using year_of_birth.
 </td>
 <td style="text-align:left;">
-For data sources with date of birth, the year should be extracted. For data sources where the year of birth is not available, the approximate year of birth could be derived based on age group categorization, if available.
+For data sources with date of birth, the year should be extracted. For
+data sources where the year of birth is not available, the approximate
+year of birth could be derived based on age group categorization, if
+available.
 </td>
 <td style="text-align:left;">
 integer
@@ -699,7 +773,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-For data sources that provide the precise date of birth, the month should be extracted and stored in this field.
+For data sources that provide the precise date of birth, the month
+should be extracted and stored in this field.
 </td>
 <td style="text-align:left;">
 integer
@@ -725,7 +800,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-For data sources that provide the precise date of birth, the day should be extracted and stored in this field.
+For data sources that provide the precise date of birth, the day should
+be extracted and stored in this field.
 </td>
 <td style="text-align:left;">
 integer
@@ -751,7 +827,15 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This field is not required but highly encouraged. For data sources that provide the precise datetime of birth, that value should be stored in this field. If birth_datetime is not provided in the source, use the following logic to infer the date: If day_of_birth is null and month_of_birth is not null then use the first of the month in that year. If month_of_birth is null or if day_of_birth AND month_of_birth are both null and the person has records during their year of birth then use the date of the earliest record, otherwise use the 15th of June of that year. If time of birth is not given use midnight (00:00:0000).
+This field is not required but highly encouraged. For data sources that
+provide the precise datetime of birth, that value should be stored in
+this field. If birth_datetime is not provided in the source, use the
+following logic to infer the date: If day_of_birth is null and
+month_of_birth is not null then use the first of the month in that year.
+If month_of_birth is null or if day_of_birth AND month_of_birth are both
+null and the person has records during their year of birth then use the
+date of the earliest record, otherwise use the 15th of June of that
+year. If time of birth is not given use midnight (00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -778,7 +862,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 This field captures race or ethnic background of the person.
 </td>
 <td style="text-align:left;">
-Only use this field if you have information about race or ethnic background. The Vocabulary contains Concepts about the main races and ethnic backgrounds in a hierarchical system. Due to the imprecise nature of human races and ethnic backgrounds, this is not a perfect system. Mixed races are not supported. If a clear race or ethnic background cannot be established, use Concept_Id 0. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Race&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Race Concepts</a>.
+Only use this field if you have information about race or ethnic
+background. The Vocabulary contains Concepts about the main races and
+ethnic backgrounds in a hierarchical system. Due to the imprecise nature
+of human races and ethnic backgrounds, this is not a perfect system.
+Mixed races are not supported. If a clear race or ethnic background
+cannot be established, use Concept_Id 0. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Race&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Race Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -804,10 +895,17 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 ethnicity_concept_id
 </td>
 <td style="text-align:left;">
-This field captures Ethnicity as defined by the Office of Management and Budget (OMB) of the US Government: it distinguishes only between “Hispanic” and “Not Hispanic”. Races and ethnic backgrounds are not stored here.
+This field captures Ethnicity as defined by the Office of Management and
+Budget (OMB) of the US Government: it distinguishes only between
+“Hispanic” and “Not Hispanic”. Races and ethnic backgrounds are not
+stored here.
 </td>
 <td style="text-align:left;">
-Only use this field if you have US-based data and a source of this information. Do not attempt to infer Ethnicity from the race or ethnic background of the Person. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Ethnicity&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted ethnicity concepts</a>
+Only use this field if you have US-based data and a source of this
+information. Do not attempt to infer Ethnicity from the race or ethnic
+background of the Person. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Ethnicity&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+ethnicity concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -833,10 +931,18 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 location_id
 </td>
 <td style="text-align:left;">
-The location refers to the physical address of the person. This field should capture the last known location of the person.
+The location refers to the physical address of the person. This field
+should capture the last known location of the person.
 </td>
 <td style="text-align:left;">
-Put the location_id from the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a> table here that represents the most granular location information for the person. This could represent anything from postal code or parts thereof, state, or county for example. Since many databases contain deidentified data, it is common that the precision of the location is reduced to prevent re-identification. This field should capture the last known location.
+Put the location_id from the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a>
+table here that represents the most granular location information for
+the person. This could represent anything from postal code or parts
+thereof, state, or county for example. Since many databases contain
+deidentified data, it is common that the precision of the location is
+reduced to prevent re-identification. This field should capture the last
+known location.
 </td>
 <td style="text-align:left;">
 integer
@@ -861,10 +967,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The Provider refers to the last known primary care provider (General Practitioner).
+The Provider refers to the last known primary care provider (General
+Practitioner).
 </td>
 <td style="text-align:left;">
-Put the provider_id from the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#provider">PROVIDER</a> table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here.
+Put the provider_id from the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#provider">PROVIDER</a>
+table of the last known general practitioner of the person. If there are
+multiple providers, it is up to the ETL to decide which to put here.
 </td>
 <td style="text-align:left;">
 integer
@@ -889,7 +999,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-The Care Site refers to where the Provider typically provides the primary care.
+The Care Site refers to where the Provider typically provides the
+primary care.
 </td>
 <td style="text-align:left;">
 </td>
@@ -916,10 +1027,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 person_source_value
 </td>
 <td style="text-align:left;">
-Use this field to link back to persons in the source data. This is typically used for error checking of ETL logic.
+Use this field to link back to persons in the source data. This is
+typically used for error checking of ETL logic.
 </td>
 <td style="text-align:left;">
-Some use cases require the ability to link back to persons in the source data. This field allows for the storing of the person value as it appears in the source. This field is not required but strongly recommended.
+Some use cases require the ability to link back to persons in the source
+data. This field allows for the storing of the person value as it
+appears in the source. This field is not required but strongly
+recommended.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -943,7 +1058,9 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 gender_source_value
 </td>
 <td style="text-align:left;">
-This field is used to store the biological sex of the person from the source data. It is not intended for use in standard analytics but for reference only.
+This field is used to store the biological sex of the person from the
+source data. It is not intended for use in standard analytics but for
+reference only.
 </td>
 <td style="text-align:left;">
 Put the biological sex of the person as it appears in the source data.
@@ -973,7 +1090,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes biological sex in a non-standard vocabulary, store the concept_id here.
+If the source data codes biological sex in a non-standard vocabulary,
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -998,7 +1116,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 race_source_value
 </td>
 <td style="text-align:left;">
-This field is used to store the race of the person from the source data. It is not intended for use in standard analytics but for reference only.
+This field is used to store the race of the person from the source data.
+It is not intended for use in standard analytics but for reference only.
 </td>
 <td style="text-align:left;">
 Put the race of the person as it appears in the source data.
@@ -1028,7 +1147,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes race in an OMOP supported vocabulary store the concept_id here.
+If the source data codes race in an OMOP supported vocabulary store the
+concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -1053,10 +1173,13 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 ethnicity_source_value
 </td>
 <td style="text-align:left;">
-This field is used to store the ethnicity of the person from the source data. It is not intended for use in standard analytics but for reference only.
+This field is used to store the ethnicity of the person from the source
+data. It is not intended for use in standard analytics but for reference
+only.
 </td>
 <td style="text-align:left;">
-If the person has an ethnicity other than the OMB standard of “Hispanic” or “Not Hispanic” store that value from the source data here.
+If the person has an ethnicity other than the OMB standard of “Hispanic”
+or “Not Hispanic” store that value from the source data here.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1083,7 +1206,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes ethnicity in an OMOP supported vocabulary, store the concept_id here.
+If the source data codes ethnicity in an OMOP supported vocabulary,
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -1109,11 +1233,44 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <div id="observation_period" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains records which define spans of time during which two conditions are expected to hold: (i) Clinical Events that happened to the Person are recorded in the Event tables, and (ii) absense of records indicate such Events did not occur during this span of time.</p>
+<p>This table contains records which define spans of time during which
+two conditions are expected to hold: (i) Clinical Events that happened
+to the Person are recorded in the Event tables, and (ii) absense of
+records indicate such Events did not occur during this span of time.</p>
 <p><strong>User Guide</strong></p>
-<p>For each Person, one or more OBSERVATION_PERIOD records may be present, but they will not overlap or be back to back to each other. Events may exist outside all of the time spans of the OBSERVATION_PERIOD records for a patient, however, absence of an Event outside these time spans cannot be construed as evidence of absence of an Event. Incidence or prevalence rates should only be calculated for the time of active OBSERVATION_PERIOD records. When constructing cohorts, outside Events can be used for inclusion criteria definition, but without any guarantee for the performance of these criteria. Also, OBSERVATION_PERIOD records can be as short as a single day, greatly disturbing the denominator of any rate calculation as part of cohort characterizations. To avoid that, apply minimal observation time as a requirement for any cohort definition.</p>
+<p>For each Person, one or more OBSERVATION_PERIOD records may be
+present, but they will not overlap or be back to back to each other.
+Events may exist outside all of the time spans of the OBSERVATION_PERIOD
+records for a patient, however, absence of an Event outside these time
+spans cannot be construed as evidence of absence of an Event. Incidence
+or prevalence rates should only be calculated for the time of active
+OBSERVATION_PERIOD records. When constructing cohorts, outside Events
+can be used for inclusion criteria definition, but without any guarantee
+for the performance of these criteria. Also, OBSERVATION_PERIOD records
+can be as short as a single day, greatly disturbing the denominator of
+any rate calculation as part of cohort characterizations. To avoid that,
+apply minimal observation time as a requirement for any cohort
+definition.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrollment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
+<p>Each Person needs to have at least one OBSERVATION_PERIOD record,
+which should represent time intervals with a high capture rate of
+Clinical Events. Some source data have very similar concepts, such as
+enrollment periods in insurance claims data. In other source data such
+as most EHR systems these time spans need to be inferred under a set of
+assumptions. It is the discretion of the ETL developer to define these
+assumptions. In many ETL solutions the start date of the first
+occurrence or the first high quality occurrence of a Clinical Event
+(Condition, Drug, Procedure, Device, Measurement, Visit) is defined as
+the start of the OBSERVATION_PERIOD record, and the end date of the last
+occurrence of last high quality occurrence of a Clinical Event, or the
+end of the database period becomes the end of the OBSERVATOIN_PERIOD for
+each Person. If a Person only has a single Clinical Event the
+OBSERVATION_PERIOD record can be as short as one day. Depending on these
+definitions it is possible that Clinical Events fall outside the time
+spans defined by OBSERVATION_PERIOD records. Family history or history
+of Clinical Events generally are not used to generate OBSERVATION_PERIOD
+records around the time they are referring to. Any two overlapping or
+adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -1152,10 +1309,12 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 observation_period_id
 </td>
 <td style="text-align:left;">
-A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id.
+A Person can have multiple discrete Observation Periods which are
+identified by the Observation_Period_Id.
 </td>
 <td style="text-align:left;">
-Assign a unique observation_period_id to each discrete Observation Period for a Person.
+Assign a unique observation_period_id to each discrete Observation
+Period for a Person.
 </td>
 <td style="text-align:left;">
 integer
@@ -1179,7 +1338,8 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The Person ID of the PERSON record for which the Observation Period is recorded.
+The Person ID of the PERSON record for which the Observation Period is
+recorded.
 </td>
 <td style="text-align:left;">
 </td>
@@ -1209,7 +1369,14 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 Use this date to determine the start date of the Observation Period.
 </td>
 <td style="text-align:left;">
-It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">PAYER_PLAN_PERIOD</a>.
+It is often the case that the idea of Observation Periods does not exist
+in source data. In those cases, the observation_period_start_date can be
+inferred as the earliest Event date available for the Person. In
+insurance claim data, the Observation Period can be considered as the
+time period the Person is enrolled with a payer. If a Person switches
+plans but stays with the same payer, and therefore capturing of data
+continues, that change would be captured in <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">PAYER_PLAN_PERIOD</a>.
 </td>
 <td style="text-align:left;">
 date
@@ -1233,10 +1400,15 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 observation_period_end_date
 </td>
 <td style="text-align:left;">
-Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded.
+Use this date to determine the end date of the period for which we can
+assume that all events for a Person are recorded.
 </td>
 <td style="text-align:left;">
-It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer.
+It is often the case that the idea of Observation Periods does not exist
+in source data. In those cases, the observation_period_end_date can be
+inferred as the last Event date available for the Person. In insurance
+claim data, the Observation Period can be considered as the time period
+the Person is enrolled with a payer.
 </td>
 <td style="text-align:left;">
 date
@@ -1260,10 +1432,18 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 period_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.
+This field can be used to determine the provenance of the Observation
+Period as in whether the period was determined from an insurance
+enrollment file, EHR healthcare encounters, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the observation_period_type_concept_id that best represents how the period was determined. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Choose the observation_period_type_concept_id that best represents how
+the period was determined. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1290,25 +1470,100 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 <div id="visit_occurrence" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains Events where Persons engage with the healthcare system for a duration of time. They are often also called “Encounters”. Visits are defined by a configuration of circumstances under which they occur, such as (i) whether the patient comes to a healthcare institution, the other way around, or the interaction is remote, (ii) whether and what kind of trained medical staff is delivering the service during the Visit, and (iii) whether the Visit is transient or for a longer period involving a stay in bed.</p>
+<p>This table contains Events where Persons engage with the healthcare
+system for a duration of time. They are often also called “Encounters”.
+Visits are defined by a configuration of circumstances under which they
+occur, such as (i) whether the patient comes to a healthcare
+institution, the other way around, or the interaction is remote, (ii)
+whether and what kind of trained medical staff is delivering the service
+during the Visit, and (iii) whether the Visit is transient or for a
+longer period involving a stay in bed.</p>
 <p><strong>User Guide</strong></p>
-<p>The configuration defining the Visit are described by Concepts in the Visit Domain, which form a hierarchical structure, but rolling up to generally familiar Visits adopted in most healthcare systems worldwide:</p>
+<p>The configuration defining the Visit are described by Concepts in the
+Visit Domain, which form a hierarchical structure, but rolling up to
+generally familiar Visits adopted in most healthcare systems
+worldwide:</p>
 <ul>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient Visit</a>: Person visiting hospital, at a Care Site, in bed, for duration of more than one day, with physicians and other Providers permanently available to deliver service around the clock</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency Room Visit</a>: Person visiting dedicated healthcare institution for treating emergencies, at a Care Site, within one day, with physicians and Providers permanently available to deliver service around the clock</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER followed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital institution Visit</a>: Person visiting dedicated institution for reasons of poor health, at a Care Site, long-term or permanently, with no physician but possibly other Providers permanently available to deliver service around the clock</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient Visit</a>: Person visiting dedicated ambulatory healthcare institution, at a Care Site, within one day, without bed, with physicians or medical Providers delivering service during Visit</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home Visit</a>: Provider visiting Person, without a Care Site, within one day, delivering service</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/5083">Telehealth Visit</a>: Patient engages with Provider through communication media</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/581458">Pharmacy Visit</a>: Person visiting pharmacy for dispensing of Drug, at a Care Site, within one day</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/32036">Laboratory Visit</a>: Patient visiting dedicated institution, at a Care Site, within one day, for the purpose of a Measurement.</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/581478">Ambulance Visit</a>: Person using transportation service for the purpose of initiating one of the other Visits, without a Care Site, within one day, potentially with Providers accompanying the Visit and delivering service</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/38004193">Case Management Visit</a>: Person interacting with healthcare system, without a Care Site, within a day, with no Providers involved, for administrative purposes</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient
+Visit</a>: Person visiting hospital, at a Care Site, in bed, for
+duration of more than one day, with physicians and other Providers
+permanently available to deliver service around the clock</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency
+Room Visit</a>: Person visiting dedicated healthcare institution for
+treating emergencies, at a Care Site, within one day, with physicians
+and Providers permanently available to deliver service around the
+clock</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency
+Room and Inpatient Visit</a>: Person visiting ER followed by a
+subsequent Inpatient Visit, where Emergency department is part of
+hospital, and transition from the ER to other hospital departments is
+undefined</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital
+institution Visit</a>: Person visiting dedicated institution for reasons
+of poor health, at a Care Site, long-term or permanently, with no
+physician but possibly other Providers permanently available to deliver
+service around the clock</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient
+Visit</a>: Person visiting dedicated ambulatory healthcare institution,
+at a Care Site, within one day, without bed, with physicians or medical
+Providers delivering service during Visit</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home
+Visit</a>: Provider visiting Person, without a Care Site, within one
+day, delivering service</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/5083">Telehealth
+Visit</a>: Patient engages with Provider through communication
+media</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/581458">Pharmacy
+Visit</a>: Person visiting pharmacy for dispensing of Drug, at a Care
+Site, within one day</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/32036">Laboratory
+Visit</a>: Patient visiting dedicated institution, at a Care Site,
+within one day, for the purpose of a Measurement.</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/581478">Ambulance
+Visit</a>: Person using transportation service for the purpose of
+initiating one of the other Visits, without a Care Site, within one day,
+potentially with Providers accompanying the Visit and delivering
+service</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/38004193">Case
+Management Visit</a>: Person interacting with healthcare system, without
+a Care Site, within a day, with no Providers involved, for
+administrative purposes</li>
 </ul>
-<p>The Visit duration, or ‘length of stay’, is defined as VISIT_END_DATE - VISIT_START_DATE. For all Visits this is &lt;1 day, except Inpatient Visits and Non-hospital institution Visits. The CDM also contains the VISIT_DETAIL table where additional information about the Visit is stored, for example, transfers between units during an inpatient Visit.</p>
+<p>The Visit duration, or ‘length of stay’, is defined as VISIT_END_DATE
+- VISIT_START_DATE. For all Visits this is &lt;1 day, except Inpatient
+Visits and Non-hospital institution Visits. The CDM also contains the
+VISIT_DETAIL table where additional information about the Visit is
+stored, for example, transfers between units during an inpatient
+Visit.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Visits can be derived easily if the source data contain coding systems for Place of Service or Procedures, like CPT codes for well visits. In those cases, the codes can be looked up and mapped to a Standard Visit Concept. Otherwise, Visit Concepts have to be identified in the ETL process. This table will contain concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. Visits can be adjacent to each other, i.e. the end date of one can be identical with the start date of the other. As a consequence, more than one-day Visits or their descendants can be recorded for the same day. Multi-day visits must not overlap, i.e. share days other than start and end days. It is often the case that some logic should be written for how to define visits and how to assign Visit_Concept_Id. For example, in US claims outpatient visits that appear to occur within the time period of an inpatient visit can be rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient visits that are within one day of each other may be strung together to create one visit. It will all depend on the source data and how encounter records should be translated to visit occurrences. Providers can be associated with a Visit through the PROVIDER_ID field, or indirectly through PROCEDURE_OCCURRENCE records linked both to the VISIT and PROVIDER tables.</p>
+<p>Visits can be derived easily if the source data contain coding
+systems for Place of Service or Procedures, like CPT codes for well
+visits. In those cases, the codes can be looked up and mapped to a
+Standard Visit Concept. Otherwise, Visit Concepts have to be identified
+in the ETL process. This table will contain concepts in the Visit
+domain. These concepts are arranged in a hierarchical structure to
+facilitate cohort definitions by rolling up to generally familiar Visits
+adopted in most healthcare systems worldwide. Visits can be adjacent to
+each other, i.e. the end date of one can be identical with the start
+date of the other. As a consequence, more than one-day Visits or their
+descendants can be recorded for the same day. Multi-day visits must not
+overlap, i.e. share days other than start and end days. It is often the
+case that some logic should be written for how to define visits and how
+to assign Visit_Concept_Id. For example, in US claims outpatient visits
+that appear to occur within the time period of an inpatient visit can be
+rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient
+visits that are within one day of each other may be strung together to
+create one visit. It will all depend on the source data and how
+encounter records should be translated to visit occurrences. Providers
+can be associated with a Visit through the PROVIDER_ID field, or
+indirectly through PROCEDURE_OCCURRENCE records linked both to the VISIT
+and PROVIDER tables.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -1347,10 +1602,14 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_occurrence_id
 </td>
 <td style="text-align:left;">
-Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit.
+Use this to identify unique interactions between a person and the health
+care system. This identifier links across the other CDM event tables to
+associate events with a visit.
 </td>
 <td style="text-align:left;">
-This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.
+This should be populated by creating a unique identifier for each unique
+interaction between a person and the healthcare system where the person
+receives a medical good or service over a span of time.
 </td>
 <td style="text-align:left;">
 integer
@@ -1400,10 +1659,19 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_concept_id
 </td>
 <td style="text-align:left;">
-This field contains a concept id representing the kind of visit, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.
+This field contains a concept id representing the kind of visit, like
+inpatient or outpatient. All concepts in this field should be standard
+and belong to the Visit domain.
 </td>
 <td style="text-align:left;">
-Populate this field based on the kind of visit that took place for the person. For example this could be “Inpatient Visit”, “Outpatient Visit”, “Ambulatory Visit”, etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Populate this field based on the kind of visit that took place for the
+person. For example this could be “Inpatient Visit”, “Outpatient Visit”,
+“Ambulatory Visit”, etc. This table will contain standard concepts in
+the Visit domain. These concepts are arranged in a hierarchical
+structure to facilitate cohort definitions by rolling up to generally
+familiar Visits adopted in most healthcare systems worldwide. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1429,10 +1697,15 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_start_date
 </td>
 <td style="text-align:left;">
-For inpatient visits, the start date is typically the admission date. For outpatient visits the start date and end date will be the same.
+For inpatient visits, the start date is typically the admission date.
+For outpatient visits the start date and end date will be the same.
 </td>
 <td style="text-align:left;">
-When populating VISIT_START_DATE, you should think about the patient experience to make decisions on how to define visits. In the case of an inpatient visit this should be the date the patient was admitted to the hospital or institution. In all other cases this should be the date of the patient-provider interaction.
+When populating VISIT_START_DATE, you should think about the patient
+experience to make decisions on how to define visits. In the case of an
+inpatient visit this should be the date the patient was admitted to the
+hospital or institution. In all other cases this should be the date of
+the patient-provider interaction.
 </td>
 <td style="text-align:left;">
 date
@@ -1458,7 +1731,8 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the start date of a visit, set it to midnight (00:00:0000).
+If no time is given for the start date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1482,10 +1756,26 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_end_date
 </td>
 <td style="text-align:left;">
-For inpatient visits the end date is typically the discharge date. If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_date, then set the visit_end_date to the date of the data pull.
+For inpatient visits the end date is typically the discharge date. If a
+Person is still an inpatient in the hospital at the time of the data
+extract and does not have a visit_end_date, then set the visit_end_date
+to the date of the data pull.
 </td>
 <td style="text-align:left;">
-Visit end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them: - Outpatient Visit: visit_end_datetime = visit_start_datetime - Emergency Room Visit: visit_end_datetime = visit_start_datetime - Inpatient Visit: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. - Non-hospital institution Visits: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs. For Inpatient Visits ongoing at the date of ETL, put date of processing the data into visit_end_datetime and visit_type_concept_id with 32220 “Still patient” to identify the visit as incomplete. - All other Visits: visit_end_datetime = visit_start_datetime. If this is a one-day visit the end date should match the start date.
+Visit end dates are mandatory. If end dates are not provided in the
+source there are three ways in which to derive them: - Outpatient Visit:
+visit_end_datetime = visit_start_datetime - Emergency Room Visit:
+visit_end_datetime = visit_start_datetime - Inpatient Visit: Usually
+there is information about discharge. If not, you should be able to
+derive the end date from the sudden decline of activity or from the
+absence of inpatient procedures/drugs. - Non-hospital institution
+Visits: Particularly for claims data, if end dates are not provided
+assume the visit is for the duration of month that it occurs. For
+Inpatient Visits ongoing at the date of ETL, put date of processing the
+data into visit_end_datetime and visit_type_concept_id with 32220 “Still
+patient” to identify the visit as incomplete. - All other Visits:
+visit_end_datetime = visit_start_datetime. If this is a one-day visit
+the end date should match the start date.
 </td>
 <td style="text-align:left;">
 date
@@ -1509,10 +1799,13 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_end_datetime
 </td>
 <td style="text-align:left;">
-If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_datetime, then set the visit_end_datetime to the datetime of the data pull.
+If a Person is still an inpatient in the hospital at the time of the
+data extract and does not have a visit_end_datetime, then set the
+visit_end_datetime to the datetime of the data pull.
 </td>
 <td style="text-align:left;">
-If no time is given for the end date of a visit, set it to midnight (00:00:0000).
+If no time is given for the end date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1536,10 +1829,17 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_type_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to understand the provenance of the visit record, or where the record comes from.
+Use this field to understand the provenance of the visit record, or
+where the record comes from.
 </td>
 <td style="text-align:left;">
-Populate this field based on the provenance of the visit record, as in whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Populate this field based on the provenance of the visit record, as in
+whether it came from an EHR record or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 Integer
@@ -1565,10 +1865,18 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.
+There will only be one provider per visit record and the ETL document
+should clearly state how they were chosen (attending, admitting, etc.).
+If there are multiple providers associated with a visit in the source,
+this can be reflected in the event tables (CONDITION_OCCURRENCE,
+PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.
 </td>
 <td style="text-align:left;">
-If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#visit_detail">VISIT_DETAIL</a> table.
+If there are multiple providers associated with a visit, you will need
+to choose which one to put here. The additional providers can be stored
+in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#visit_detail">VISIT_DETAIL</a>
+table.
 </td>
 <td style="text-align:left;">
 integer
@@ -1593,7 +1901,8 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-This field provides information about the Care Site where the Visit took place.
+This field provides information about the Care Site where the Visit took
+place.
 </td>
 <td style="text-align:left;">
 There should only be one Care Site associated with a Visit.
@@ -1621,10 +1930,16 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)
+This field houses the verbatim value from the source data representing
+the kind of visit that took place (inpatient, outpatient, emergency,
+etc.)
 </td>
 <td style="text-align:left;">
-If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -&gt; ER-&gt; OP. This should line up with the logic chosen to determine how visits are created.
+If there is information about the kind of visit in the source data that
+value should be stored here. If a visit is an amalgamation of visits
+from the source then use a hierarchy to choose the visit source value,
+such as IP -&gt; ER-&gt; OP. This should line up with the logic chosen
+to determine how visits are created.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1650,7 +1965,9 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the visit source value is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -1675,10 +1992,15 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 admitted_from_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.
+Use this field to determine where the patient was admitted from. This
+concept is part of the visit domain and can indicate if a patient was
+admitted to the hospital from a long-term care facility, for example.
 </td>
 <td style="text-align:left;">
-If available, map the admitted_from_source_value to a standard concept in the visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. If a person was admitted from home, set this to 0.
+If available, map the admitted_from_source_value to a standard concept
+in the visit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. If a person was admitted from home, set this to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -1706,7 +2028,10 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+admitted from. Typically this applies only to visits that have a length
+of stay, like inpatient visits or long-term care visits.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1730,10 +2055,18 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 discharged_to_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was transferred to another hospital or sent to a long-term care facility, for example. It is assumed that a person is discharged to home therefore there is not a standard concept id for “home”. Use concept id = 0 when a person is discharged to home.
+Use this field to determine where the patient was discharged to after a
+visit. This concept is part of the visit domain and can indicate if a
+patient was transferred to another hospital or sent to a long-term care
+facility, for example. It is assumed that a person is discharged to home
+therefore there is not a standard concept id for “home”. Use concept id
+= 0 when a person is discharged to home.
 </td>
 <td style="text-align:left;">
-If available, map the discharged_to_source_value to a standard concept in the visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If available, map the discharged_to_source_value to a standard concept
+in the visit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1761,7 +2094,11 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+discharged to after a visit, as in they went home or were moved to
+long-term care. Typically this applies only to visits that have a length
+of stay of a day or more.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1785,10 +2122,13 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 preceding_visit_occurrence_id
 </td>
 <td style="text-align:left;">
-Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between.
+Use this field to find the visit that occurred for the person prior to
+the given visit. There could be a few days or a few years in between.
 </td>
 <td style="text-align:left;">
-This field can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
+This field can be used to link a visit immediately preceding the current
+visit. Note this is not symmetrical, and there is no such thing as a
+“following_visit_id”.
 </td>
 <td style="text-align:left;">
 integer
@@ -1814,11 +2154,38 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <div id="visit_detail" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <p><strong>Table Description</strong></p>
-<p>The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.</p>
+<p>The VISIT_DETAIL table is an optional table used to represents
+details of each record in the parent VISIT_OCCURRENCE table. A good
+example of this would be the movement between units in a hospital during
+an inpatient stay or claim lines associated with a one insurance claim.
+For every record in the VISIT_OCCURRENCE table there may be 0 or more
+records in the VISIT_DETAIL table with a 1:n relationship where n may be
+0. The VISIT_DETAIL table is structurally very similar to
+VISIT_OCCURRENCE table and belongs to the visit domain.</p>
 <p><strong>User Guide</strong></p>
-<p>The configuration defining the Visit Detail is described by Concepts in the Visit Domain, which form a hierarchical structure. The Visit Detail record will have an associated to the Visit Occurrence record in two ways: <br> 1. The Visit Detail record will have the VISIT_OCCURRENCE_ID it is associated to 2. The VISIT_DETAIL_CONCEPT_ID will be a descendant of the VISIT_CONCEPT_ID for the Visit.</p>
+<p>The configuration defining the Visit Detail is described by Concepts
+in the Visit Domain, which form a hierarchical structure. The Visit
+Detail record will have an associated to the Visit Occurrence record in
+two ways: <br> 1. The Visit Detail record will have the
+VISIT_OCCURRENCE_ID it is associated to 2. The VISIT_DETAIL_CONCEPT_ID
+will be a descendant of the VISIT_CONCEPT_ID for the Visit.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>It is not mandatory that the VISIT_DETAIL table be filled in, but if you find that the logic to create VISIT_OCCURRENCE records includes the roll-up of multiple smaller records to create one picture of a Visit then it is a good idea to use VISIT_DETAIL. In EHR data, for example, a Person may be in the hospital but instead of one over-arching Visit their encounters are recorded as times they interacted with a health care provider. A Person in the hospital interacts with multiple providers multiple times a day so the encounters must be strung together using some heuristic (defined by the ETL) to identify the entire Visit. In this case the encounters would be considered Visit Details and the entire Visit would be the Visit Occurrence. In this example it is also possible to use the Vocabulary to distinguish Visit Details from a Visit Occurrence by setting the VISIT_CONCEPT_ID to <a href="https://athena.ohdsi.org/search-terms/terms/9201">9201</a> and the VISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicate where the patient was in the hospital at the time of care.</p>
+<p>It is not mandatory that the VISIT_DETAIL table be filled in, but if
+you find that the logic to create VISIT_OCCURRENCE records includes the
+roll-up of multiple smaller records to create one picture of a Visit
+then it is a good idea to use VISIT_DETAIL. In EHR data, for example, a
+Person may be in the hospital but instead of one over-arching Visit
+their encounters are recorded as times they interacted with a health
+care provider. A Person in the hospital interacts with multiple
+providers multiple times a day so the encounters must be strung together
+using some heuristic (defined by the ETL) to identify the entire Visit.
+In this case the encounters would be considered Visit Details and the
+entire Visit would be the Visit Occurrence. In this example it is also
+possible to use the Vocabulary to distinguish Visit Details from a Visit
+Occurrence by setting the VISIT_CONCEPT_ID to <a
+href="https://athena.ohdsi.org/search-terms/terms/9201">9201</a> and the
+VISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicate
+where the patient was in the hospital at the time of care.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -1857,10 +2224,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail.
+Use this to identify unique interactions between a person and the health
+care system. This identifier links across the other CDM event tables to
+associate events with a visit detail.
 </td>
 <td style="text-align:left;">
-This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.
+This should be populated by creating a unique identifier for each unique
+interaction between a person and the healthcare system where the person
+receives a medical good or service over a span of time.
 </td>
 <td style="text-align:left;">
 integer
@@ -1910,10 +2281,19 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_concept_id
 </td>
 <td style="text-align:left;">
-This field contains a concept id representing the kind of visit detail, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.
+This field contains a concept id representing the kind of visit detail,
+like inpatient or outpatient. All concepts in this field should be
+standard and belong to the Visit domain.
 </td>
 <td style="text-align:left;">
-Populate this field based on the kind of visit that took place for the person. For example this could be “Inpatient Visit”, “Outpatient Visit”, “Ambulatory Visit”, etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Populate this field based on the kind of visit that took place for the
+person. For example this could be “Inpatient Visit”, “Outpatient Visit”,
+“Ambulatory Visit”, etc. This table will contain standard concepts in
+the Visit domain. These concepts are arranged in a hierarchical
+structure to facilitate cohort definitions by rolling up to generally
+familiar Visits adopted in most healthcare systems worldwide. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1939,10 +2319,13 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_start_date
 </td>
 <td style="text-align:left;">
-This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with.
+This is the date of the start of the encounter. This may or may not be
+equal to the date of the Visit the Visit Detail is associated with.
 </td>
 <td style="text-align:left;">
-When populating VISIT_DETAIL_START_DATE, you should think about the patient experience to make decisions on how to define visits. Most likely this should be the date of the patient-provider interaction.
+When populating VISIT_DETAIL_START_DATE, you should think about the
+patient experience to make decisions on how to define visits. Most
+likely this should be the date of the patient-provider interaction.
 </td>
 <td style="text-align:left;">
 date
@@ -1968,7 +2351,8 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the start date of a visit, set it to midnight (00:00:0000).
+If no time is given for the start date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1992,10 +2376,27 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_end_date
 </td>
 <td style="text-align:left;">
-This the end date of the patient-provider interaction. If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_date, then set the visit_end_date to the date of the data pull.
+This the end date of the patient-provider interaction. If a Person is
+still an inpatient in the hospital at the time of the data extract and
+does not have a visit_end_date, then set the visit_end_date to the date
+of the data pull.
 </td>
 <td style="text-align:left;">
-Visit Detail end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them:<br> - Outpatient Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Emergency Room Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Inpatient Visit Detail: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. - Non-hospital institution Visit Details: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs.<br> For Inpatient Visit Details ongoing at the date of ETL, put date of processing the data into visit_detai_end_datetime and visit_detail_type_concept_id with 32220 “Still patient” to identify the visit as incomplete. All other Visits Details: visit_detail_end_datetime = visit_detail_start_datetime.
+Visit Detail end dates are mandatory. If end dates are not provided in
+the source there are three ways in which to derive them:<br> -
+Outpatient Visit Detail: visit_detail_end_datetime =
+visit_detail_start_datetime - Emergency Room Visit Detail:
+visit_detail_end_datetime = visit_detail_start_datetime - Inpatient
+Visit Detail: Usually there is information about discharge. If not, you
+should be able to derive the end date from the sudden decline of
+activity or from the absence of inpatient procedures/drugs. -
+Non-hospital institution Visit Details: Particularly for claims data, if
+end dates are not provided assume the visit is for the duration of month
+that it occurs.<br> For Inpatient Visit Details ongoing at the date of
+ETL, put date of processing the data into visit_detai_end_datetime and
+visit_detail_type_concept_id with 32220 “Still patient” to identify the
+visit as incomplete. All other Visits Details: visit_detail_end_datetime
+= visit_detail_start_datetime.
 </td>
 <td style="text-align:left;">
 date
@@ -2019,10 +2420,13 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_end_datetime
 </td>
 <td style="text-align:left;">
-If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_datetime, then set the visit_end_datetime to the datetime of the data pull.
+If a Person is still an inpatient in the hospital at the time of the
+data extract and does not have a visit_end_datetime, then set the
+visit_end_datetime to the datetime of the data pull.
 </td>
 <td style="text-align:left;">
-If no time is given for the end date of a visit, set it to midnight (00:00:0000).
+If no time is given for the end date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -2046,10 +2450,17 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_type_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to understand the provenance of the visit detail record, or where the record comes from.
+Use this field to understand the provenance of the visit detail record,
+or where the record comes from.
 </td>
 <td style="text-align:left;">
-Populate this field based on the provenance of the visit detail record, as in whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Populate this field based on the provenance of the visit detail record,
+as in whether it came from an EHR record or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2075,10 +2486,16 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-There will only be one provider per <strong>visit</strong> record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record.
+There will only be one provider per <strong>visit</strong> record and
+the ETL document should clearly state how they were chosen (attending,
+admitting, etc.). This is a typical reason for leveraging the
+VISIT_DETAIL table as even though each VISIT_DETAIL record can only have
+one provider, there is no limit to the number of VISIT_DETAIL records
+that can be associated to a VISIT_OCCURRENCE record.
 </td>
 <td style="text-align:left;">
-The additional providers associated to a Visit can be stored in this table where each VISIT_DETAIL record represents a different provider.
+The additional providers associated to a Visit can be stored in this
+table where each VISIT_DETAIL record represents a different provider.
 </td>
 <td style="text-align:left;">
 integer
@@ -2103,7 +2520,8 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-This field provides information about the Care Site where the Visit Detail took place.
+This field provides information about the Care Site where the Visit
+Detail took place.
 </td>
 <td style="text-align:left;">
 There should only be one Care Site associated with a Visit Detail.
@@ -2131,10 +2549,16 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)
+This field houses the verbatim value from the source data representing
+the kind of visit detail that took place (inpatient, outpatient,
+emergency, etc.)
 </td>
 <td style="text-align:left;">
-If there is information about the kind of visit detail in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the VISIT_DETAIL_SOURCE_VALUE, such as IP -&gt; ER-&gt; OP. This should line up with the logic chosen to determine how visits are created.
+If there is information about the kind of visit detail in the source
+data that value should be stored here. If a visit is an amalgamation of
+visits from the source then use a hierarchy to choose the
+VISIT_DETAIL_SOURCE_VALUE, such as IP -&gt; ER-&gt; OP. This should line
+up with the logic chosen to determine how visits are created.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2160,7 +2584,9 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an
+OMOP supported vocabulary put the concept id representing the source
+value here.
 </td>
 <td style="text-align:left;">
 Integer
@@ -2185,10 +2611,15 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 admitted_from_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.
+Use this field to determine where the patient was admitted from. This
+concept is part of the visit domain and can indicate if a patient was
+admitted to the hospital from a long-term care facility, for example.
 </td>
 <td style="text-align:left;">
-If available, map the admitted_from_source_value to a standard concept in the visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. If the person was admitted from home, set this to 0.
+If available, map the admitted_from_source_value to a standard concept
+in the visit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. If the person was admitted from home, set this to 0.
 </td>
 <td style="text-align:left;">
 Integer
@@ -2216,7 +2647,10 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+admitted from. Typically this applies only to visits that have a length
+of stay, like inpatient visits or long-term care visits.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2242,7 +2676,11 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+discharged to after a visit, as in they went home or were moved to
+long-term care. Typically this applies only to visits that have a length
+of stay of a day or more.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2266,10 +2704,18 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 discharged_to_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was transferred to another hospital or sent to a long-term care facility, for example. It is assumed that a person is discharged to home therefore there is not a standard concept id for “home”. Use concept id = 0 when a person is discharged to home.
+Use this field to determine where the patient was discharged to after a
+visit. This concept is part of the visit domain and can indicate if a
+patient was transferred to another hospital or sent to a long-term care
+facility, for example. It is assumed that a person is discharged to home
+therefore there is not a standard concept id for “home”. Use concept id
+= 0 when a person is discharged to home.
 </td>
 <td style="text-align:left;">
-If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in
+the Visit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2295,10 +2741,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 preceding_visit_detail_id
 </td>
 <td style="text-align:left;">
-Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.
+Use this field to find the visit detail that occurred for the person
+prior to the given visit detail record. There could be a few days or a
+few years in between.
 </td>
 <td style="text-align:left;">
-The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
+The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately
+preceding the current Visit Detail. Note this is not symmetrical, and
+there is no such thing as a “following_visit_id”.
 </td>
 <td style="text-align:left;">
 integer
@@ -2323,10 +2773,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 parent_visit_detail_id
 </td>
 <td style="text-align:left;">
-Use this field to find the visit detail that subsumes the given visit detail record. This is used in the case that a visit detail record needs to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.
+Use this field to find the visit detail that subsumes the given visit
+detail record. This is used in the case that a visit detail record needs
+to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.
 </td>
 <td style="text-align:left;">
-If there are multiple nested levels to how Visits are represented in the source, the VISIT_DETAIL_PARENT_ID can be used to record this relationship.
+If there are multiple nested levels to how Visits are represented in the
+source, the VISIT_DETAIL_PARENT_ID can be used to record this
+relationship.
 </td>
 <td style="text-align:left;">
 integer
@@ -2377,14 +2831,47 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 </tbody>
 </table>
 </div>
-<div id="condition_occurrence" class="section level3 tabset tabset-pills">
+<div id="condition_occurrence"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.</p>
+<p>This table contains records of Events of a Person suggesting the
+presence of a disease or medical condition stated as a diagnosis, a
+sign, or a symptom, which is either observed by a Provider or reported
+by the patient.</p>
 <p><strong>User Guide</strong></p>
-<p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype definitions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p>
+<p>Conditions are defined by Concepts from the Condition domain, which
+form a complex hierarchy. As a result, the same Person with the same
+disease may have multiple Condition records, which belong to the same
+hierarchical family. Most Condition records are mapped from diagnostic
+codes, but recorded signs, symptoms and summary descriptions also
+contribute to this table. Rule out diagnoses should not be recorded in
+this table, but in reality their negating nature is not always captured
+in the source data, and other precautions must be taken when when
+identifying Persons who should suffer from the recorded Condition.
+Record all conditions as they exist in the source data. Any decisions
+about diagnosis/phenotype definitions would be done through cohort
+specifications. These cohorts can be housed in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a>
+table. Conditions span a time interval from start to end, but are
+typically recorded as single snapshot records with no end date. The
+reason is twofold: (i) At the time of the recording the duration is not
+known and later not recorded, and (ii) the Persons typically cease
+interacting with the healthcare system when they feel better, which
+leads to incomplete capture of resolved Conditions. The <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a>
+table addresses this issue. Family history and past diagnoses (‘history
+of’) are not recorded in this table. Instead, they are listed in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a>
+table. Codes written in the process of establishing the diagnosis, such
+as ‘question of’ of and ‘rule out’, should not represented here.
+Instead, they should be recorded in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a>
+table, if they are used for analyses. However, this information is not
+always available.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.</p>
+<p>Source codes and source text fields mapped to Standard Concepts of
+the Condition Domain have to be recorded here.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -2423,10 +2910,16 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_occurrence_id
 </td>
 <td style="text-align:left;">
-The unique key given to a condition record for a person. Refer to the ETL for how duplicate conditions during the same visit were handled.
+The unique key given to a condition record for a person. Refer to the
+ETL for how duplicate conditions during the same visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a condition present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same condition within the same visit. It is valid to keep these duplicates and assign them individual, unique, CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be handled.
+Each instance of a condition present in the source data should be
+assigned this unique key. In some cases, a person can have multiple
+records of the same condition within the same visit. It is valid to keep
+these duplicates and assign them individual, unique,
+CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be
+handled.
 </td>
 <td style="text-align:left;">
 integer
@@ -2477,10 +2970,16 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_concept_id
 </td>
 <td style="text-align:left;">
-The CONDITION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a condition
+The CONDITION_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies. This is the standard
+concept mapped from the source value which represents a condition
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records whose source values map to concepts with a domain of “Condition” should go in this table. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Condition&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records
+whose source values map to concepts with a domain of “Condition” should
+go in this table. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Condition&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2509,7 +3008,10 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 Use this date to determine the start date of the condition
 </td>
 <td style="text-align:left;">
-Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE.
+Most often data sources do not have the idea of a start date for a
+condition. Rather, if a source only has one date associated with a
+condition record it is acceptable to use that date for both the
+CONDITION_START_DATE and the CONDITION_END_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -2535,7 +3037,8 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+If a source does not specify datetime the convention is to set the time
+to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -2562,7 +3065,10 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 Use this date to determine the end date of the condition
 </td>
 <td style="text-align:left;">
-Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE.
+Most often data sources do not have the idea of a start date for a
+condition. Rather, if a source only has one date associated with a
+condition record it is acceptable to use that date for both the
+CONDITION_START_DATE and the CONDITION_END_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -2588,7 +3094,8 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+If a source does not specify datetime the convention is to set the time
+to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -2612,10 +3119,18 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Condition
+record, as in whether the condition was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance of the record. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance
+of the record. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2641,10 +3156,18 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_status_concept_id
 </td>
 <td style="text-align:left;">
-This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others.
+This concept represents the point during the visit the diagnosis was
+given (admitting diagnosis, final diagnosis), whether the diagnosis was
+determined due to laboratory findings, if the diagnosis was
+exclusionary, or if it was a preliminary diagnosis, among others.
 </td>
 <td style="text-align:left;">
-Choose the Concept in the Condition Status domain that best represents the point during the visit when the diagnosis was given. These can include admitting diagnosis, principal diagnosis, and secondary diagnosis. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the Concept in the Condition Status domain that best represents
+the point during the visit when the diagnosis was given. These can
+include admitting diagnosis, principal diagnosis, and secondary
+diagnosis. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2670,10 +3193,13 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 stop_reason
 </td>
 <td style="text-align:left;">
-The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring.
+The Stop Reason indicates why a Condition is no longer valid with
+respect to the purpose within the source data. Note that a Stop Reason
+does not necessarily imply that the condition is no longer occurring.
 </td>
 <td style="text-align:left;">
-This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist.
+This information is often not populated in source data and it is a valid
+etl choice to leave it blank if the information does not exist.
 </td>
 <td style="text-align:left;">
 varchar(20)
@@ -2697,10 +3223,14 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with condition record, e.g. the provider who made the diagnosis or the provider who recorded the symptom.
+The provider associated with condition record, e.g. the provider who
+made the diagnosis or the provider who recorded the symptom.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record, for
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -2728,7 +3258,13 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 The visit during which the condition occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If a CONDITION_START_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE record.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If a CONDITION_START_DATE occurs within the
+start and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE
+record.
 </td>
 <td style="text-align:left;">
 integer
@@ -2753,7 +3289,11 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the condition occurred. For example, if the person was in the ICU at the time of the diagnosis the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the condition occurred. For
+example, if the person was in the ICU at the time of the diagnosis the
+VISIT_OCCURRENCE record would reflect the overall hospital stay and the
+VISIT_DETAIL record would reflect the ICU stay during the hospital
+visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -2781,10 +3321,13 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the condition that occurred. For example, this could be an ICD10 or Read code.
+This field houses the verbatim value from the source data representing
+the condition that occurred. For example, this could be an ICD10 or Read
+code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2808,10 +3351,19 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the condition source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Condition necessary for a given analytic use case. Consider using CONDITION_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the condition source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Condition
+necessary for a given analytic use case. Consider using
+CONDITION_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -2836,10 +3388,15 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_status_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the condition status.
+This field houses the verbatim value from the source data representing
+the condition status.
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating when and how a diagnosis was given to a patient. This source value is mapped to a standard concept which is stored in the CONDITION_STATUS_CONCEPT_ID field.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating when and how a
+diagnosis was given to a patient. This source value is mapped to a
+standard concept which is stored in the CONDITION_STATUS_CONCEPT_ID
+field.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2864,11 +3421,34 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <div id="drug_exposure" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table captures records about the exposure to a Drug ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain biochemical effect on the metabolism. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.</p>
+<p>This table captures records about the exposure to a Drug ingested or
+otherwise introduced into the body. A Drug is a biochemical substance
+formulated in such a way that when administered to a Person it will
+exert a certain biochemical effect on the metabolism. Drugs include
+prescription and over-the-counter medicines, vaccines, and
+large-molecule biologic therapies. Radiological devices ingested or
+applied locally do not count as Drugs.</p>
 <p><strong>User Guide</strong></p>
-<p>The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.</p>
+<p>The purpose of records in this table is to indicate an exposure to a
+certain drug as best as possible. In this context a drug is defined as
+an active ingredient. Drug Exposures are defined by Concepts from the
+Drug domain, which form a complex hierarchy. As a result, one
+DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is
+a combination product. Records in this table represent prescriptions
+written, prescriptions dispensed, and drugs administered by a provider
+to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter
+on these types. This table includes additional information about the
+drug products, the quantity given, and route of administration.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs administered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p>
+<p>Information about quantity and dose is provided in a variety of
+different ways and it is important for the ETL to provide as much
+information as possible from the data. Depending on the provenance of
+the data fields may be captured differently i.e. quantity for drugs
+administered may have a separate meaning from quantity for prescriptions
+dispensed. If a patient has multiple records on the same day for the
+same drug or procedures the ETL should not de-dupe them unless there is
+probable reason to believe the item is a true data duplicate. Take note
+on how to handle refills for prescriptions written.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -2907,10 +3487,17 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_exposure_id
 </td>
 <td style="text-align:left;">
-The unique key given to records of drug dispensings or administrations for a person. Refer to the ETL for how duplicate drugs during the same visit were handled.
+The unique key given to records of drug dispensings or administrations
+for a person. Refer to the ETL for how duplicate drugs during the same
+visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a drug dispensing or administration present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same drug within the same visit. It is valid to keep these duplicates and assign them individual, unique, DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be handled.
+Each instance of a drug dispensing or administration present in the
+source data should be assigned this unique key. In some cases, a person
+can have multiple records of the same drug within the same visit. It is
+valid to keep these duplicates and assign them individual, unique,
+DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be
+handled.
 </td>
 <td style="text-align:left;">
 integer
@@ -2934,7 +3521,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the PERSON for whom the drug dispensing or administration is recorded. This may be a system generated code.
+The PERSON_ID of the PERSON for whom the drug dispensing or
+administration is recorded. This may be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -2961,10 +3549,35 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_concept_id
 </td>
 <td style="text-align:left;">
-The DRUG_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a drug product or molecule otherwise introduced to the body. The drug concepts can have a varying degree of information about drug strength and dose. This information is relevant in the context of quantity and administration information in the subsequent fields plus strength information from the DRUG_STRENGTH table, provided as part of the standard vocabulary download.
+The DRUG_CONCEPT_ID field is recommended for primary use in analyses,
+and must be used for network studies. This is the standard concept
+mapped from the source concept id which represents a drug product or
+molecule otherwise introduced to the body. The drug concepts can have a
+varying degree of information about drug strength and dose. This
+information is relevant in the context of quantity and administration
+information in the subsequent fields plus strength information from the
+DRUG_STRENGTH table, provided as part of the standard vocabulary
+download.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should be derived either from mapping from the source concept id or by picking the drug concept representing the most amount of detail you have. Records whose source values map to standard concepts with a domain of Drug should go in this table. When the Drug Source Value of the code cannot be translated into Standard Drug Concept IDs, a Drug exposure entry is stored with only the corresponding SOURCE_CONCEPT_ID and DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the most detailed content of information is preferred during the mapping process. These are indicated in the CONCEPT_CLASS_ID field of the Concept and are recorded in the following order of precedence: ‘Branded Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical Drug Form’, and only if no other information is available ‘Ingredient’. Note: If only the drug class is known, the DRUG_CONCEPT_ID field should contain 0. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Drug&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should
+be derived either from mapping from the source concept id or by picking
+the drug concept representing the most amount of detail you have.
+Records whose source values map to standard concepts with a domain of
+Drug should go in this table. When the Drug Source Value of the code
+cannot be translated into Standard Drug Concept IDs, a Drug exposure
+entry is stored with only the corresponding SOURCE_CONCEPT_ID and
+DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the
+most detailed content of information is preferred during the mapping
+process. These are indicated in the CONCEPT_CLASS_ID field of the
+Concept and are recorded in the following order of precedence: ‘Branded
+Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug
+Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical
+Drug Form’, and only if no other information is available ‘Ingredient’.
+Note: If only the drug class is known, the DRUG_CONCEPT_ID field should
+contain 0. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Drug&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2993,7 +3606,10 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 Use this date to determine the start date of the drug record.
 </td>
 <td style="text-align:left;">
-Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration was recorded. It is a valid ETL choice to use the date the drug was ordered as the DRUG_EXPOSURE_START_DATE.
+Valid entries include a start date of a prescription, the date a
+prescription was filled, or the date on which a Drug administration was
+recorded. It is a valid ETL choice to use the date the drug was ordered
+as the DRUG_EXPOSURE_START_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -3019,7 +3635,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -3043,10 +3660,27 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_exposure_end_date
 </td>
 <td style="text-align:left;">
-The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.
+The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for
+the patient.
 </td>
 <td style="text-align:left;">
-If this information is not explicitly available in the data, infer the end date using the following methods:<br><br> 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL) 200*5/20 = 50 days. <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples by dose form</a>
+If this information is not explicitly available in the data, infer the
+end date using the following methods:<br><br> 1. Start first with
+duration or days supply using the calculation drug start date + days
+supply -1 day. 2. Use quantity divided by daily dose that you may obtain
+from the sig or a source field (or assumed daily dose of 1) for solid,
+indivisibile, drug products. If quantity represents ingredient amount,
+quantity divided by daily dose * concentration (from drug_strength) drug
+concept id tells you the dose form. 3. If it is an administration
+record, set drug end date equal to drug start date. If the record is a
+written prescription then set end date to start date + 29. If the record
+is a mail-order prescription set end date to start date + 89. The end
+date must be equal to or greater than the start date. Ibuprofen 20mg/mL
+oral solution concept tells us this is oral solution. Calculate duration
+as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL)
+200*5/20 = 50 days. <a
+href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples
+by dose form</a>
 </td>
 <td style="text-align:left;">
 date
@@ -3072,7 +3706,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -3096,10 +3731,12 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 verbatim_end_date
 </td>
 <td style="text-align:left;">
-This is the end date of the drug exposure as it appears in the source data, if it is given
+This is the end date of the drug exposure as it appears in the source
+data, if it is given
 </td>
 <td style="text-align:left;">
-Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable.
+Put the end date or discontinuation date as it appears from the source
+data or leave blank if unavailable.
 </td>
 <td style="text-align:left;">
 date
@@ -3123,10 +3760,19 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_type_concept_id
 </td>
 <td style="text-align:left;">
-You can use the TYPE_CONCEPT_ID to delineate between prescriptions written vs. prescriptions dispensed vs. medication history vs. patient-reported exposure, etc.
+You can use the TYPE_CONCEPT_ID to delineate between prescriptions
+written vs. prescriptions dispensed vs. medication history
+vs. patient-reported exposure, etc.
 </td>
 <td style="text-align:left;">
-Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Choose the drug_type_concept_id that best represents the provenance of
+the record, for example whether it came from a record of a prescription
+written or physician administered drug. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3152,10 +3798,13 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 stop_reason
 </td>
 <td style="text-align:left;">
-The reason a person stopped a medication as it is represented in the source. Reasons include regimen completed, changed, removed, etc. This field will be retired in v6.0.
+The reason a person stopped a medication as it is represented in the
+source. Reasons include regimen completed, changed, removed, etc. This
+field will be retired in v6.0.
 </td>
 <td style="text-align:left;">
-This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist.
+This information is often not populated in source data and it is a valid
+etl choice to leave it blank if the information does not exist.
 </td>
 <td style="text-align:left;">
 varchar(20)
@@ -3179,7 +3828,9 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 refills
 </td>
 <td style="text-align:left;">
-This is only filled in when the record is coming from a prescription written this field is meant to represent intended refills at time of the prescription.
+This is only filled in when the record is coming from a prescription
+written this field is meant to represent intended refills at time of the
+prescription.
 </td>
 <td style="text-align:left;">
 </td>
@@ -3207,7 +3858,22 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-To find the dose form of a drug the RELATIONSHIP table can be used where the relationship_id is ‘Has dose form’. If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the DRUG_STRENGTH table the quantity should be converted to the correct unit given in DRUG_STRENGTH. For clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160. Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similar to clinical drugs. Please see <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to calculate drug dose</a> for more information.
+To find the dose form of a drug the RELATIONSHIP table can be used where
+the relationship_id is ‘Has dose form’. If liquid, quantity stands for
+the total amount dispensed or ordered of ingredient in the units given
+by the drug_strength table. If the unit from the source data does not
+align with the unit in the DRUG_STRENGTH table the quantity should be
+converted to the correct unit given in DRUG_STRENGTH. For clinical drugs
+with fixed dose forms (tablets etc.) the quantity is the number of
+units/tablets/capsules prescribed or dispensed (can be partial, but then
+only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms
+(injections) the quantity is the amount of ingredient the patient got.
+For example, if the injection is 2mg/mL but the patient got 80mL then
+quantity is reported as 160. Quantified clinical drugs with divisible
+dose forms (prefilled syringes), the quantity is the amount of
+ingredient similar to clinical drugs. Please see <a
+href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to
+calculate drug dose</a> for more information.
 </td>
 <td style="text-align:left;">
 float
@@ -3233,7 +3899,10 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Days supply of the drug. This should be the verbatim days_supply as given on the prescription. If the drug is physician administered use duration end date if given or set to 1 as default if duration is not available.
+Days supply of the drug. This should be the verbatim days_supply as
+given on the prescription. If the drug is physician administered use
+duration end date if given or set to 1 as default if duration is not
+available.
 </td>
 <td style="text-align:left;">
 integer
@@ -3257,10 +3926,12 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 sig
 </td>
 <td style="text-align:left;">
-This is the verbatim instruction for the drug as written by the provider.
+This is the verbatim instruction for the drug as written by the
+provider.
 </td>
 <td style="text-align:left;">
-Put the written out instructions for the drug as it is verbatim in the source, if available.
+Put the written out instructions for the drug as it is verbatim in the
+source, if available.
 </td>
 <td style="text-align:left;">
 varchar(MAX)
@@ -3286,7 +3957,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route domain.
+The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route
+domain.
 </td>
 <td style="text-align:left;">
 integer
@@ -3337,10 +4009,14 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The Provider associated with drug record, e.g. the provider who wrote the prescription or the provider who administered the drug.
+The Provider associated with drug record, e.g. the provider who wrote
+the prescription or the provider who administered the drug.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the ordering vs administering physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record, for
+example the ordering vs administering physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -3365,10 +4041,12 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 visit_occurrence_id
 </td>
 <td style="text-align:left;">
-The Visit during which the drug was prescribed, administered or dispensed.
+The Visit during which the drug was prescribed, administered or
+dispensed.
 </td>
 <td style="text-align:left;">
-To populate this field drug exposures must be explicitly initiated in the visit.
+To populate this field drug exposures must be explicitly initiated in
+the visit.
 </td>
 <td style="text-align:left;">
 integer
@@ -3393,7 +4071,11 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the drug exposure occurred. For example, if the person was in the ICU at the time of the drug administration the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the drug exposure occurred. For
+example, if the person was in the ICU at the time of the drug
+administration the VISIT_OCCURRENCE record would reflect the overall
+hospital stay and the VISIT_DETAIL record would reflect the ICU stay
+during the hospital visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -3421,10 +4103,13 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the drug exposure that occurred. For example, this could be an NDC or Gemscript code.
+This field houses the verbatim value from the source data representing
+the drug exposure that occurred. For example, this could be an NDC or
+Gemscript code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Drug Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Drug Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3448,10 +4133,19 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the drug source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Drug necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the drug source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Drug
+necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID
+instead to enable standardized analytics that can be consistent across
+the network.
 </td>
 <td style="text-align:left;">
-If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -3476,10 +4170,14 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 route_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the drug route.
+This field houses the verbatim value from the source data representing
+the drug route.
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating when and how a drug was given to a patient. This source value is mapped to a standard concept which is stored in the ROUTE_CONCEPT_ID field.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating when and how a drug
+was given to a patient. This source value is mapped to a standard
+concept which is stored in the ROUTE_CONCEPT_ID field.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3503,10 +4201,14 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 dose_unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the dose unit of the drug given.
+This field houses the verbatim value from the source data representing
+the dose unit of the drug given.
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating the unit of dosage of drug given to the patient. <strong>This is an older column and will be deprecated in an upcoming version.</strong>
+This information may be called something different in the source data
+but the field is meant to contain a value indicating the unit of dosage
+of drug given to the patient. <strong>This is an older column and will
+be deprecated in an upcoming version.</strong>
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3528,14 +4230,31 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 </tbody>
 </table>
 </div>
-<div id="procedure_occurrence" class="section level3 tabset tabset-pills">
+<div id="procedure_occurrence"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.</p>
+<p>This table contains records of activities or processes ordered by, or
+carried out by, a healthcare provider on the patient with a diagnostic
+or therapeutic purpose.</p>
 <p><strong>User Guide</strong></p>
-<p>Lab tests are not a procedure, if something is observed with an expected resulting amount and unit then it should be a measurement. Phlebotomy is a procedure but so trivial that it tends to be rarely captured. It can be assumed that there is a phlebotomy procedure associated with many lab tests, therefore it is unnecessary to add them as separate procedures. If the user finds the same procedure over concurrent days, it is assumed those records are part of a procedure lasting more than a day. This logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM.</p>
+<p>Lab tests are not a procedure, if something is observed with an
+expected resulting amount and unit then it should be a measurement.
+Phlebotomy is a procedure but so trivial that it tends to be rarely
+captured. It can be assumed that there is a phlebotomy procedure
+associated with many lab tests, therefore it is unnecessary to add them
+as separate procedures. If the user finds the same procedure over
+concurrent days, it is assumed those records are part of a procedure
+lasting more than a day. This logic is in lieu of the
+procedure_end_date, which will be added in a future version of the
+CDM.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are: - Same Procedure - Same PROCEDURE_DATETIME - Same Visit Occurrence or Visit Detail - Same Provider - Same Modifier for Procedures. Source codes and source text fields mapped to Standard Concepts of the Procedure Domain have to be recorded here.</p>
+<p>When dealing with duplicate records, the ETL must determine whether
+to sum them up into one record or keep them separate. Things to consider
+are: - Same Procedure - Same PROCEDURE_DATETIME - Same Visit Occurrence
+or Visit Detail - Same Provider - Same Modifier for Procedures. Source
+codes and source text fields mapped to Standard Concepts of the
+Procedure Domain have to be recorded here.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -3574,10 +4293,16 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_occurrence_id
 </td>
 <td style="text-align:left;">
-The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled.
+The unique key given to a procedure record for a person. Refer to the
+ETL for how duplicate procedures during the same visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled.
+Each instance of a procedure occurrence in the source data should be
+assigned this unique key. In some cases, a person can have multiple
+records of the same procedure within the same visit. It is valid to keep
+these duplicates and assign them individual, unique,
+PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be
+handled.
 </td>
 <td style="text-align:left;">
 integer
@@ -3601,7 +4326,8 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the PERSON for whom the procedure is recorded. This may be a system generated code.
+The PERSON_ID of the PERSON for whom the procedure is recorded. This may
+be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -3628,10 +4354,16 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_concept_id
 </td>
 <td style="text-align:left;">
-The PROCEDURE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a procedure
+The PROCEDURE_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies. This is the standard
+concept mapped from the source value which represents a procedure
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records whose source values map to standard concepts with a domain of “Procedure” should go in this table. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Procedure&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records
+whose source values map to standard concepts with a domain of
+“Procedure” should go in this table. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Procedure&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3660,7 +4392,9 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 Use this date to determine the date the procedure started.
 </td>
 <td style="text-align:left;">
-This is meant to be the <strong>start date</strong> of the procedure. It will be renamed in a future version to <strong>PROCEDURE_START_DATE</strong>.
+This is meant to be the <strong>start date</strong> of the procedure. It
+will be renamed in a future version to
+<strong>PROCEDURE_START_DATE</strong>.
 </td>
 <td style="text-align:left;">
 date
@@ -3686,7 +4420,9 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the procedure has a start time in the native date, use this field to house that information. This will be renamed in a future version to <strong>PROCEDURE_START_DATETIME</strong>.
+If the procedure has a start time in the native date, use this field to
+house that information. This will be renamed in a future version to
+<strong>PROCEDURE_START_DATETIME</strong>.
 </td>
 <td style="text-align:left;">
 datetime
@@ -3713,7 +4449,8 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 Use this field to house the date that the procedure ended.
 </td>
 <td style="text-align:left;">
-This is meant to be the end date of the procedure. It is not required and for most cases will be the same as the PROCEDURE_START_DATE.
+This is meant to be the end date of the procedure. It is not required
+and for most cases will be the same as the PROCEDURE_START_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -3740,7 +4477,9 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 Use this field to house the datetime that the procedure ended.
 </td>
 <td style="text-align:left;">
-This is meant to house the end datetime of the procedure and will most often be used in conjunction with the procedure_start_datetime to determine the length of the procedure.
+This is meant to house the end datetime of the procedure and will most
+often be used in conjunction with the procedure_start_datetime to
+determine the length of the procedure.
 </td>
 <td style="text-align:left;">
 datetime
@@ -3764,10 +4503,20 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Procedure record, as in whether the procedure was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Procedure
+record, as in whether the procedure was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. If a procedure is recorded as an EHR encounter, the PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance
+of the record, for example whether it came from an EHR record or billing
+claim. If a procedure is recorded as an EHR encounter, the
+PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3793,10 +4542,17 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 modifier_concept_id
 </td>
 <td style="text-align:left;">
-The modifiers are intended to give additional information about the procedure but as of now the vocabulary is under review.
+The modifiers are intended to give additional information about the
+procedure but as of now the vocabulary is under review.
 </td>
 <td style="text-align:left;">
-It is up to the ETL to choose how to map modifiers if they exist in source data. These concepts are typically distinguished by ‘Modifier’ concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’ vocabulary). If there is more than one modifier on a record, one should be chosen that pertains to the procedure rather than provider. <a href="https://athena.ohdsi.org/search-terms/terms?conceptClass=CPT4+Modifier&amp;conceptClass=HCPCS+Modifier&amp;vocabulary=CPT4&amp;vocabulary=HCPCS&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+It is up to the ETL to choose how to map modifiers if they exist in
+source data. These concepts are typically distinguished by ‘Modifier’
+concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’
+vocabulary). If there is more than one modifier on a record, one should
+be chosen that pertains to the procedure rather than provider. <a
+href="https://athena.ohdsi.org/search-terms/terms?conceptClass=CPT4+Modifier&amp;conceptClass=HCPCS+Modifier&amp;vocabulary=CPT4&amp;vocabulary=HCPCS&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3824,7 +4580,9 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 If the quantity value is omitted, a single procedure is assumed.
 </td>
 <td style="text-align:left;">
-If a Procedure has a quantity of ‘0’ in the source, this should default to ‘1’ in the ETL. If there is a record in the source it can be assumed the exposure occurred at least once
+If a Procedure has a quantity of ‘0’ in the source, this should default
+to ‘1’ in the ETL. If there is a record in the source it can be assumed
+the exposure occurred at least once
 </td>
 <td style="text-align:left;">
 integer
@@ -3848,10 +4606,14 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with the procedure record, e.g. the provider who performed the Procedure.
+The provider associated with the procedure record, e.g. the provider who
+performed the Procedure.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record, for
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -3879,7 +4641,13 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 The visit during which the procedure occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If a PROCEDURE_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE record.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If a PROCEDURE_DATE occurs within the start
+and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE
+record.
 </td>
 <td style="text-align:left;">
 integer
@@ -3904,7 +4672,11 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the Procedure occurred. For example, if the Person was in the ICU at the time of the Procedure the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the Procedure occurred. For
+example, if the Person was in the ICU at the time of the Procedure the
+VISIT_OCCURRENCE record would reflect the overall hospital stay and the
+VISIT_DETAIL record would reflect the ICU stay during the hospital
+visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -3932,10 +4704,13 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the procedure that occurred. For example, this could be an CPT4 or OPCS4 code.
+This field houses the verbatim value from the source data representing
+the procedure that occurred. For example, this could be an CPT4 or OPCS4
+code.
 </td>
 <td style="text-align:left;">
-Use this value to look up the source concept id and then map the source concept id to a standard concept id.
+Use this value to look up the source concept id and then map the source
+concept id to a standard concept id.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3959,10 +4734,19 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the procedure source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Procedure necessary for a given analytic use case. Consider using PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the procedure source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Procedure
+necessary for a given analytic use case. Consider using
+PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -4014,11 +4798,21 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 <div id="device_exposure" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <p><strong>Table Description</strong></p>
-<p>The Device domain captures information about a person’s exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).</p>
+<p>The Device domain captures information about a person’s exposure to a
+foreign physical object or instrument which is used for diagnostic or
+therapeutic purposes through a mechanism beyond chemical action. Devices
+include implantable objects (e.g. pacemakers, stents, artificial
+joints), medical equipment and supplies (e.g. bandages, crutches,
+syringes), other instruments used in medical procedures (e.g. sutures,
+defibrillators) and material used in clinical care (e.g. adhesives, body
+material, dental material, surgical material).</p>
 <p><strong>User Guide</strong></p>
-<p>The distinction between Devices or supplies and Procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.</p>
+<p>The distinction between Devices or supplies and Procedures are
+sometimes blurry, but the former are physical objects while the latter
+are actions, often to apply a Device or supply.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Source codes and source text fields mapped to Standard Concepts of the Device Domain have to be recorded here.</p>
+<p>Source codes and source text fields mapped to Standard Concepts of
+the Device Domain have to be recorded here.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -4057,10 +4851,12 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_exposure_id
 </td>
 <td style="text-align:left;">
-The unique key given to records a person’s exposure to a foreign physical object or instrument.
+The unique key given to records a person’s exposure to a foreign
+physical object or instrument.
 </td>
 <td style="text-align:left;">
-Each instance of an exposure to a foreign object or device present in the source data should be assigned this unique key.
+Each instance of an exposure to a foreign object or device present in
+the source data should be assigned this unique key.
 </td>
 <td style="text-align:left;">
 integer
@@ -4110,7 +4906,10 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_concept_id
 </td>
 <td style="text-align:left;">
-The DEVICE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a foreign object or instrument the person was exposed to.
+The DEVICE_CONCEPT_ID field is recommended for primary use in analyses,
+and must be used for network studies. This is the standard concept
+mapped from the source concept id which represents a foreign object or
+instrument the person was exposed to.
 </td>
 <td style="text-align:left;">
 The CONCEPT_ID that the DEVICE_SOURCE_VALUE maps to.
@@ -4142,7 +4941,9 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 Use this date to determine the start date of the device record.
 </td>
 <td style="text-align:left;">
-Valid entries include a start date of a procedure to implant a device, the date of a prescription for a device, or the date of device administration.
+Valid entries include a start date of a procedure to implant a device,
+the date of a prescription for a device, or the date of device
+administration.
 </td>
 <td style="text-align:left;">
 date
@@ -4168,7 +4969,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -4192,10 +4994,12 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_exposure_end_date
 </td>
 <td style="text-align:left;">
-The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended for the patient, if given.
+The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended
+for the patient, if given.
 </td>
 <td style="text-align:left;">
-Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable.
+Put the end date or discontinuation date as it appears from the source
+data or leave blank if unavailable.
 </td>
 <td style="text-align:left;">
 date
@@ -4221,7 +5025,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+If a source does not specify datetime the convention is to set the time
+to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -4245,10 +5050,18 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_type_concept_id
 </td>
 <td style="text-align:left;">
-You can use the TYPE_CONCEPT_ID to denote the provenance of the record, as in whether the record is from administrative claims or EHR.
+You can use the TYPE_CONCEPT_ID to denote the provenance of the record,
+as in whether the record is from administrative claims or EHR.
 </td>
 <td style="text-align:left;">
-Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Choose the drug_type_concept_id that best represents the provenance of
+the record, for example whether it came from a record of a prescription
+written or physician administered drug. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -4274,10 +5087,13 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 unique_device_id
 </td>
 <td style="text-align:left;">
-This is the Unique Device Identification (UDI-DI) number for devices regulated by the FDA, if given.
+This is the Unique Device Identification (UDI-DI) number for devices
+regulated by the FDA, if given.
 </td>
 <td style="text-align:left;">
-For medical devices that are regulated by the FDA, a Unique Device Identification (UDI) is provided if available in the data source and is recorded in the UNIQUE_DEVICE_ID field.
+For medical devices that are regulated by the FDA, a Unique Device
+Identification (UDI) is provided if available in the data source and is
+recorded in the UNIQUE_DEVICE_ID field.
 </td>
 <td style="text-align:left;">
 varchar(255)
@@ -4301,7 +5117,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 production_id
 </td>
 <td style="text-align:left;">
-This is the Production Identifier (UDI-PI) portion of the Unique Device Identification.
+This is the Production Identifier (UDI-PI) portion of the Unique Device
+Identification.
 </td>
 <td style="text-align:left;">
 </td>
@@ -4352,10 +5169,13 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The Provider associated with device record, e.g. the provider who wrote the prescription or the provider who implanted the device.
+The Provider associated with device record, e.g. the provider who wrote
+the prescription or the provider who implanted the device.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record.
 </td>
 <td style="text-align:left;">
 integer
@@ -4383,7 +5203,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 The Visit during which the device was prescribed or given.
 </td>
 <td style="text-align:left;">
-To populate this field device exposures must be explicitly initiated in the visit.
+To populate this field device exposures must be explicitly initiated in
+the visit.
 </td>
 <td style="text-align:left;">
 integer
@@ -4411,7 +5232,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 The Visit Detail during which the device was prescribed or given.
 </td>
 <td style="text-align:left;">
-To populate this field device exposures must be explicitly initiated in the visit detail record.
+To populate this field device exposures must be explicitly initiated in
+the visit detail record.
 </td>
 <td style="text-align:left;">
 integer
@@ -4436,10 +5258,13 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the device exposure that occurred. For example, this could be an NDC or Gemscript code.
+This field houses the verbatim value from the source data representing
+the device exposure that occurred. For example, this could be an NDC or
+Gemscript code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Device Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4463,10 +5288,19 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the device source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Device necessary for a given analytic use case. Consider using DEVICE_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the device source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Device
+necessary for a given analytic use case. Consider using
+DEVICE_CONCEPT_ID instead to enable standardized analytics that can be
+consistent across the network.
 </td>
 <td style="text-align:left;">
-If the DEVICE_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the DEVICE_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -4491,10 +5325,14 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 unit_concept_id
 </td>
 <td style="text-align:left;">
-UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit domain that best represents the unit as given in the source data.
+UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit
+domain that best represents the unit as given in the source data.
 </td>
 <td style="text-align:left;">
-There is no standardization requirement for units associated with DEVICE_CONCEPT_IDs, however, it is the responsibility of the ETL to choose the most plausible unit. If there is no unit associated with a Device record, set to NULL.
+There is no standardization requirement for units associated with
+DEVICE_CONCEPT_IDs, however, it is the responsibility of the ETL to
+choose the most plausible unit. If there is no unit associated with a
+Device record, set to NULL.
 </td>
 <td style="text-align:left;">
 integer
@@ -4520,10 +5358,16 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the unit of the Device. For example, blood transfusions are considered devices and can be given in mL quantities.
+This field houses the verbatim value from the source data representing
+the unit of the Device. For example, blood transfusions are considered
+devices and can be given in mL quantities.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference. Using the blood transfusion example, blood transfusion is represented by the DEVICE_CONCEPT_ID and the unit (mL) would be housed in the UNIT_SOURCE_VALUE and mapped to a standard concept in the unit domain.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference. Using
+the blood transfusion example, blood transfusion is represented by the
+DEVICE_CONCEPT_ID and the unit (mL) would be housed in the
+UNIT_SOURCE_VALUE and mapped to a standard concept in the unit domain.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4547,10 +5391,19 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 unit_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Unit necessary for a given analytic use case. Consider using UNIT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the UNIT_SOURCE_VALUE and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Unit
+necessary for a given analytic use case. Consider using UNIT_CONCEPT_ID
+instead to enable standardized analytics that can be consistent across
+the network.
 </td>
 <td style="text-align:left;">
-If the UNIT_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the UNIT_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -4576,11 +5429,47 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <div id="measurement" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <p><strong>Table Description</strong></p>
-<p>The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a PROCEDURE_OCCURRENCE record for each measurement if one does not exist in the source data. Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. If there is no result, it is assumed that the lab test was conducted but the result was not captured.</p>
+<p>The MEASUREMENT table contains records of Measurements,
+i.e. structured values (numerical or categorical) obtained through
+systematic and standardized examination or testing of a Person or
+Person’s sample. The MEASUREMENT table contains both orders and results
+of such Measurements as laboratory tests, vital signs, quantitative
+findings from pathology reports, etc. Measurements are stored as
+attribute value pairs, with the attribute as the Measurement Concept and
+the value representing the result. The value can be a Concept (stored in
+VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit
+(UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in
+the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a
+PROCEDURE_OCCURRENCE record for each measurement if one does not exist
+in the source data. Measurements differ from Observations in that they
+require a standardized test or some other activity to generate a
+quantitative or qualitative result. If there is no result, it is assumed
+that the lab test was conducted but the result was not captured.</p>
 <p><strong>User Guide</strong></p>
-<p>Measurements are predominately lab tests with a few exceptions, like blood pressure or function tests. Results are given in the form of a value and unit combination. When investigating measurements, look for operator_concept_ids (&lt;, &gt;, etc.).</p>
+<p>Measurements are predominately lab tests with a few exceptions, like
+blood pressure or function tests. Results are given in the form of a
+value and unit combination. When investigating measurements, look for
+operator_concept_ids (&lt;, &gt;, etc.).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Only records where the source value maps to a Concept in the measurement domain should be included in this table. Even though each Measurement always has a result, the fields VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are not mandatory as often the result is not given in the source data. When the result is not known, the Measurement record represents just the fact that the corresponding Measurement was carried out, which in itself is already useful information for some use cases. For some Measurement Concepts, the result is included in the test. For example, ICD10 CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/45548980">45548980</a> ‘Abnormal level of unspecified serum enzyme’ indicates a Measurement and the result (abnormal). In those situations, the CONCEPT_RELATIONSHIP table in addition to the ‘Maps to’ record contains a second record with the relationship_id set to ‘Maps to value’. In this example, the ‘Maps to’ relationship directs to <a href="https://athena.ohdsi.org/search-terms/terms/4046263">4046263</a> ‘Enzyme measurement’ as well as a ‘Maps to value’ record to <a href="https://athena.ohdsi.org/search-terms/terms/4135493">4135493</a> ‘Abnormal’.</p>
+<p>Only records where the source value maps to a Concept in the
+measurement domain should be included in this table. Even though each
+Measurement always has a result, the fields VALUE_AS_NUMBER and
+VALUE_AS_CONCEPT_ID are not mandatory as often the result is not given
+in the source data. When the result is not known, the Measurement record
+represents just the fact that the corresponding Measurement was carried
+out, which in itself is already useful information for some use cases.
+For some Measurement Concepts, the result is included in the test. For
+example, ICD10 CONCEPT_ID <a
+href="https://athena.ohdsi.org/search-terms/terms/45548980">45548980</a>
+‘Abnormal level of unspecified serum enzyme’ indicates a Measurement and
+the result (abnormal). In those situations, the CONCEPT_RELATIONSHIP
+table in addition to the ‘Maps to’ record contains a second record with
+the relationship_id set to ‘Maps to value’. In this example, the ‘Maps
+to’ relationship directs to <a
+href="https://athena.ohdsi.org/search-terms/terms/4046263">4046263</a>
+‘Enzyme measurement’ as well as a ‘Maps to value’ record to <a
+href="https://athena.ohdsi.org/search-terms/terms/4135493">4135493</a>
+‘Abnormal’.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -4619,10 +5508,15 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_id
 </td>
 <td style="text-align:left;">
-The unique key given to a Measurement record for a Person. Refer to the ETL for how duplicate Measurements during the same Visit were handled.
+The unique key given to a Measurement record for a Person. Refer to the
+ETL for how duplicate Measurements during the same Visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a measurement present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same measurement within the same visit. It is valid to keep these duplicates and assign them individual, unique, MEASUREMENT_IDs, though it is up to the ETL how they should be handled.
+Each instance of a measurement present in the source data should be
+assigned this unique key. In some cases, a person can have multiple
+records of the same measurement within the same visit. It is valid to
+keep these duplicates and assign them individual, unique,
+MEASUREMENT_IDs, though it is up to the ETL how they should be handled.
 </td>
 <td style="text-align:left;">
 integer
@@ -4646,7 +5540,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the Person for whom the Measurement is recorded. This may be a system generated code.
+The PERSON_ID of the Person for whom the Measurement is recorded. This
+may be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -4673,10 +5568,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_concept_id
 </td>
 <td style="text-align:left;">
-The MEASUREMENT_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
+The MEASUREMENT_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain of “Measurement” should go in this table.
+The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only
+records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain
+of “Measurement” should go in this table.
 </td>
 <td style="text-align:left;">
 integer
@@ -4705,7 +5603,9 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 Use this date to determine the date of the measurement.
 </td>
 <td style="text-align:left;">
-If there are multiple dates in the source data associated with a record such as order_date, draw_date, and result_date, choose the one that is closest to the date the sample was drawn from the patient.
+If there are multiple dates in the source data associated with a record
+such as order_date, draw_date, and result_date, choose the one that is
+closest to the date the sample was drawn from the patient.
 </td>
 <td style="text-align:left;">
 date
@@ -4731,7 +5631,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -4757,7 +5658,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is present for backwards compatibility and will be deprecated in an upcoming version.
+This is present for backwards compatibility and will be deprecated in an
+upcoming version.
 </td>
 <td style="text-align:left;">
 varchar(10)
@@ -4781,10 +5683,19 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Measurement record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Measurement
+record, as in whether the measurement was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the
+provenance of the record, for example whether it came from an EHR record
+or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -4810,10 +5721,18 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 operator_concept_id
 </td>
 <td style="text-align:left;">
-The meaning of Concept <a href="https://athena.ohdsi.org/search-terms/terms/4172703">4172703</a> for ‘=’ is identical to omission of a OPERATOR_CONCEPT_ID value. Since the use of this field is rare, it’s important when devising analyses to not to forget testing for the content of this field for values different from =.
+The meaning of Concept <a
+href="https://athena.ohdsi.org/search-terms/terms/4172703">4172703</a>
+for ‘=’ is identical to omission of a OPERATOR_CONCEPT_ID value. Since
+the use of this field is rare, it’s important when devising analyses to
+not to forget testing for the content of this field for values different
+from =.
 </td>
 <td style="text-align:left;">
-Operators are =, &gt; and these concepts belong to the ‘Meas Value Operator’ domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Operators are =, &gt; and these concepts belong to the ‘Meas Value
+Operator’ domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -4838,10 +5757,29 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 value_as_number
 </td>
 <td style="text-align:left;">
-This is the numerical value of the Result of the Measurement, if available. Note that measurements such as blood pressures will be split into their component parts i.e. one record for systolic, one record for diastolic.
+This is the numerical value of the Result of the Measurement, if
+available. Note that measurements such as blood pressures will be split
+into their component parts i.e. one record for systolic, one record for
+diastolic.
 </td>
 <td style="text-align:left;">
-If there is a negative value coming from the source, set the VALUE_AS_NUMBER to NULL, with the exception of the following Measurements (listed as LOINC codes):<br>- <a href="https://athena.ohdsi.org/search-terms/terms/3003396">1925-7</a> Base excess in Arterial blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3002032">1927-3</a> Base excess in Venous blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3006277">8632-2</a> QRS-Axis - <a href="https://athena.ohdsi.org/search-terms/terms/3012501">11555-0</a> Base excess in Blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3003129">1926-5</a> Base excess in Capillary blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3004959">28638-5</a> Base excess in Arterial cord blood by calculation <a href="https://athena.ohdsi.org/search-terms/terms/3007435">28639-3</a> Base excess in Venous cord blood by calculation
+If there is a negative value coming from the source, set the
+VALUE_AS_NUMBER to NULL, with the exception of the following
+Measurements (listed as LOINC codes):<br>- <a
+href="https://athena.ohdsi.org/search-terms/terms/3003396">1925-7</a>
+Base excess in Arterial blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3002032">1927-3</a>
+Base excess in Venous blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3006277">8632-2</a>
+QRS-Axis - <a
+href="https://athena.ohdsi.org/search-terms/terms/3012501">11555-0</a>
+Base excess in Blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3003129">1926-5</a>
+Base excess in Capillary blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3004959">28638-5</a>
+Base excess in Arterial cord blood by calculation <a
+href="https://athena.ohdsi.org/search-terms/terms/3007435">28639-3</a>
+Base excess in Venous cord blood by calculation
 </td>
 <td style="text-align:left;">
 float
@@ -4865,10 +5803,16 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 value_as_concept_id
 </td>
 <td style="text-align:left;">
-If the raw data gives a categorial result for measurements those values are captured and mapped to standard concepts in the ‘Meas Value’ domain.
+If the raw data gives a categorial result for measurements those values
+are captured and mapped to standard concepts in the ‘Meas Value’ domain.
 </td>
 <td style="text-align:left;">
-If the raw data provides categorial results as well as continuous results for measurements, it is a valid ETL choice to preserve both values. The continuous value should go in the VALUE_AS_NUMBER field and the categorical value should be mapped to a standard concept in the ‘Meas Value’ domain and put in the VALUE_AS_CONCEPT_ID field. This is also the destination for the ‘Maps to value’ relationship.
+If the raw data provides categorial results as well as continuous
+results for measurements, it is a valid ETL choice to preserve both
+values. The continuous value should go in the VALUE_AS_NUMBER field and
+the categorical value should be mapped to a standard concept in the
+‘Meas Value’ domain and put in the VALUE_AS_CONCEPT_ID field. This is
+also the destination for the ‘Maps to value’ relationship.
 </td>
 <td style="text-align:left;">
 integer
@@ -4893,10 +5837,16 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 unit_concept_id
 </td>
 <td style="text-align:left;">
-There is currently no recommended unit for individual measurements, i.e. it is not mandatory to represent Hemoglobin a1C measurements as a percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit domain that best represents the unit as given in the source data.
+There is currently no recommended unit for individual measurements,
+i.e. it is not mandatory to represent Hemoglobin a1C measurements as a
+percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in
+the Unit domain that best represents the unit as given in the source
+data.
 </td>
 <td style="text-align:left;">
-There is no standardization requirement for units associated with MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to choose the most plausible unit.
+There is no standardization requirement for units associated with
+MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to
+choose the most plausible unit.
 </td>
 <td style="text-align:left;">
 integer
@@ -4922,10 +5872,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 range_low
 </td>
 <td style="text-align:left;">
-Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and should remain NULL if not given.
+Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are
+provided by the source and should remain NULL if not given.
 </td>
 <td style="text-align:left;">
-If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the RANGE_HIGH and RANGE_LOW fields. This should be set to NULL if not provided.
+If reference ranges for upper and lower limit of normal as provided
+(typically by a laboratory) these are stored in the RANGE_HIGH and
+RANGE_LOW fields. This should be set to NULL if not provided.
 </td>
 <td style="text-align:left;">
 float
@@ -4949,10 +5902,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 range_high
 </td>
 <td style="text-align:left;">
-Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and should remain NULL if not given.
+Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are
+provided by the source and should remain NULL if not given.
 </td>
 <td style="text-align:left;">
-If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the RANGE_HIGH and RANGE_LOW fields. This should be set to NULL if not provided.
+If reference ranges for upper and lower limit of normal as provided
+(typically by a laboratory) these are stored in the RANGE_HIGH and
+RANGE_LOW fields. This should be set to NULL if not provided.
 </td>
 <td style="text-align:left;">
 float
@@ -4976,10 +5932,14 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with measurement record, e.g. the provider who ordered the test or the provider who recorded the result.
+The provider associated with measurement record, e.g. the provider who
+ordered the test or the provider who recorded the result.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record. For
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -5007,7 +5967,15 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 The visit during which the Measurement occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If a MEASUREMENT_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a measurement is related to a visit explicitly in the source data, it is possible that the result date of the Measurement falls outside of the bounds of the Visit dates.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If a MEASUREMENT_DATE occurs within the start
+and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a
+measurement is related to a visit explicitly in the source data, it is
+possible that the result date of the Measurement falls outside of the
+bounds of the Visit dates.
 </td>
 <td style="text-align:left;">
 integer
@@ -5032,7 +6000,10 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the Measurement occurred. For
+example, if the Person was in the ICU at the time the VISIT_OCCURRENCE
+record would reflect the overall hospital stay and the VISIT_DETAIL
+record would reflect the ICU stay during the hospital visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -5060,10 +6031,14 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the Measurement that occurred. For example, this could be an ICD10 or Read code.
+This field houses the verbatim value from the source data representing
+the Measurement that occurred. For example, this could be an ICD10 or
+Read code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Measurement Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Measurement Concept in the
+Standardized Vocabularies and the original code is stored here for
+reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5087,10 +6062,19 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the MEASUREMENT_SOURCE_VALUE and may
+not necessarily be standard. This field is discouraged from use in
+analysis because it is not required to contain Standard Concepts that
+are used across the OHDSI community, and should only be used when
+Standard Concepts do not adequately represent the source detail for the
+Measurement necessary for a given analytic use case. Consider using
+MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the MEASUREMENT_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the MEASUREMENT_SOURCE_VALUE is coded in the source data using an
+OMOP supported vocabulary put the concept id representing the source
+value here.
 </td>
 <td style="text-align:left;">
 integer
@@ -5115,10 +6099,12 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the unit of the Measurement that occurred.
+This field houses the verbatim value from the source data representing
+the unit of the Measurement that occurred.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5142,10 +6128,19 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 unit_source_concept_id
 </td>
 <td style="text-align:left;">
-“This is the concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using UNIT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.”
+“This is the concept representing the UNIT_SOURCE_VALUE and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the
+Measurement necessary for a given analytic use case. Consider using
+UNIT_CONCEPT_ID instead to enable standardized analytics that can be
+consistent across the network.”
 </td>
 <td style="text-align:left;">
-If the UNIT_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the UNIT_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here.
 </td>
 <td style="text-align:left;">
 integer
@@ -5170,10 +6165,14 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 value_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim result value of the Measurement from the source data .
+This field houses the verbatim result value of the Measurement from the
+source data .
 </td>
 <td style="text-align:left;">
-If both a continuous and categorical result are given in the source data such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both included, store the verbatim value that was mapped to VALUE_AS_CONCEPT_ID here.
+If both a continuous and categorical result are given in the source data
+such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both
+included, store the verbatim value that was mapped to
+VALUE_AS_CONCEPT_ID here.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5197,7 +6196,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_event_id
 </td>
 <td style="text-align:left;">
-If the Measurement record is related to another record in the database, this field is the primary key of the linked record.
+If the Measurement record is related to another record in the database,
+this field is the primary key of the linked record.
 </td>
 <td style="text-align:left;">
 Put the primary key of the linked record, if applicable, here.
@@ -5224,10 +6224,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 meas_event_field_concept_id
 </td>
 <td style="text-align:left;">
-If the Measurement record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from.
+If the Measurement record is related to another record in the database,
+this field is the CONCEPT_ID that identifies which table the primary key
+of the linked record came from.
 </td>
 <td style="text-align:left;">
-Put the CONCEPT_ID that identifies which table and field the MEASUREMENT_EVENT_ID came from.
+Put the CONCEPT_ID that identifies which table and field the
+MEASUREMENT_EVENT_ID came from.
 </td>
 <td style="text-align:left;">
 integer
@@ -5253,11 +6256,35 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <div id="observation" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">OBSERVATION</h3>
 <p><strong>Table Description</strong></p>
-<p>The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here.</p>
+<p>The OBSERVATION table captures clinical facts about a Person obtained
+in the context of examination, questioning or a procedure. Any data that
+cannot be represented by any other domains, such as social and lifestyle
+facts, medical history, family history, etc. are recorded here.</p>
 <p><strong>User Guide</strong></p>
-<p>Observations differ from Measurements in that they do not require a standardized test or some other activity to generate clinical fact. Typical observations are medical history, family history, the stated need for certain treatment, social circumstances, lifestyle choices, healthcare utilization patterns, etc. If the generation clinical facts requires a standardized testing such as lab testing or imaging and leads to a standardized result, the data item is recorded in the MEASUREMENT table. If the clinical fact observed determines a sign, symptom, diagnosis of a disease or other medical condition, it is recorded in the CONDITION_OCCURRENCE table. Valid Observation Concepts are not enforced to be from any domain though they still should be Standard Concepts.</p>
+<p>Observations differ from Measurements in that they do not require a
+standardized test or some other activity to generate clinical fact.
+Typical observations are medical history, family history, the stated
+need for certain treatment, social circumstances, lifestyle choices,
+healthcare utilization patterns, etc. If the generation clinical facts
+requires a standardized testing such as lab testing or imaging and leads
+to a standardized result, the data item is recorded in the MEASUREMENT
+table. If the clinical fact observed determines a sign, symptom,
+diagnosis of a disease or other medical condition, it is recorded in the
+CONDITION_OCCURRENCE table. Valid Observation Concepts are not enforced
+to be from any domain though they still should be Standard Concepts.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Records whose Source Values map to any domain besides Condition, Procedure, Drug, Measurement or Device should be stored in the Observation table. Observations can be stored as attribute value pairs, with the attribute as the Observation Concept and the value representing the clinical fact. This fact can be a Concept (stored in VALUE_AS_CONCEPT), a numerical value (VALUE_AS_NUMBER), a verbatim string (VALUE_AS_STRING), or a datetime (VALUE_AS_DATETIME). Even though Observations do not have an explicit result, the clinical fact can be stated separately from the type of Observation in the VALUE_AS_* fields. It is recommended for Observations that are suggestive statements of positive assertion should have a value of ‘Yes’ (concept_id=4188539), recorded, even though the null value is the equivalent.</p>
+<p>Records whose Source Values map to any domain besides Condition,
+Procedure, Drug, Measurement or Device should be stored in the
+Observation table. Observations can be stored as attribute value pairs,
+with the attribute as the Observation Concept and the value representing
+the clinical fact. This fact can be a Concept (stored in
+VALUE_AS_CONCEPT), a numerical value (VALUE_AS_NUMBER), a verbatim
+string (VALUE_AS_STRING), or a datetime (VALUE_AS_DATETIME). Even though
+Observations do not have an explicit result, the clinical fact can be
+stated separately from the type of Observation in the VALUE_AS_* fields.
+It is recommended for Observations that are suggestive statements of
+positive assertion should have a value of ‘Yes’ (concept_id=4188539),
+recorded, even though the null value is the equivalent.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -5296,10 +6323,12 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_id
 </td>
 <td style="text-align:left;">
-The unique key given to an Observation record for a Person. Refer to the ETL for how duplicate Observations during the same Visit were handled.
+The unique key given to an Observation record for a Person. Refer to the
+ETL for how duplicate Observations during the same Visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of an observation present in the source data should be assigned this unique key.
+Each instance of an observation present in the source data should be
+assigned this unique key.
 </td>
 <td style="text-align:left;">
 integer
@@ -5323,7 +6352,8 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the Person for whom the Observation is recorded. This may be a system generated code.
+The PERSON_ID of the Person for whom the Observation is recorded. This
+may be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5350,10 +6380,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_concept_id
 </td>
 <td style="text-align:left;">
-The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
+The OBSERVATION_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domains MUST go to the corresponding table.
+The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is
+no specified domain that the Concepts in this table must adhere to. The
+only rule is that records with Concepts in the Condition, Procedure,
+Drug, Measurement, or Device domains MUST go to the corresponding table.
 </td>
 <td style="text-align:left;">
 integer
@@ -5378,10 +6412,13 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_date
 </td>
 <td style="text-align:left;">
-The date of the Observation. Depending on what the Observation represents this could be the date of a lab test, the date of a survey, or the date a patient’s family history was taken.
+The date of the Observation. Depending on what the Observation
+represents this could be the date of a lab test, the date of a survey,
+or the date a patient’s family history was taken.
 </td>
 <td style="text-align:left;">
-For some observations the ETL may need to make a choice as to which date to choose.
+For some observations the ETL may need to make a choice as to which date
+to choose.
 </td>
 <td style="text-align:left;">
 date
@@ -5431,10 +6468,19 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Observation record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Observation
+record, as in whether the measurement was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the
+provenance of the record, for example whether it came from an EHR record
+or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -5460,7 +6506,10 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_number
 </td>
 <td style="text-align:left;">
-This is the numerical value of the Result of the Observation, if applicable and available. It is not expected that all Observations will have numeric results, rather, this field is here to house values should they exist.
+This is the numerical value of the Result of the Observation, if
+applicable and available. It is not expected that all Observations will
+have numeric results, rather, this field is here to house values should
+they exist.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5486,7 +6535,8 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_string
 </td>
 <td style="text-align:left;">
-This is the categorical value of the Result of the Observation, if applicable and available.
+This is the categorical value of the Result of the Observation, if
+applicable and available.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5512,10 +6562,29 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_concept_id
 </td>
 <td style="text-align:left;">
-It is possible that some records destined for the Observation table have two clinical ideas represented in one source code. This is common with ICD10 codes that describe a family history of some Condition, for example. In OMOP the Vocabulary breaks these two clinical ideas into two codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the VALUE_AS_CONCEPT_ID. It is important when using the Observation table to keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID field for relevant information.
+It is possible that some records destined for the Observation table have
+two clinical ideas represented in one source code. This is common with
+ICD10 codes that describe a family history of some Condition, for
+example. In OMOP the Vocabulary breaks these two clinical ideas into two
+codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the
+VALUE_AS_CONCEPT_ID. It is important when using the Observation table to
+keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID
+field for relevant information.
 </td>
 <td style="text-align:left;">
-Note that the value of VALUE_AS_CONCEPT_ID may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the ‘Maps to’ record contains a second record with the relationship_id set to ‘Maps to value’. For example, ICD10 <a href="https://athena.ohdsi.org/search-terms/terms/45581076">Z82.4</a> ‘Family history of ischaemic heart disease and other diseases of the circulatory system’ has a ‘Maps to’ relationship to <a href="https://athena.ohdsi.org/search-terms/terms/4167217">4167217</a> ‘Family history of clinical finding’ as well as a ‘Maps to value’ record to <a href="https://athena.ohdsi.org/search-terms/terms/134057">134057</a> ‘Disorder of cardiovascular system’.
+Note that the value of VALUE_AS_CONCEPT_ID may be provided through
+mapping from a source Concept which contains the content of the
+Observation. In those situations, the CONCEPT_RELATIONSHIP table in
+addition to the ‘Maps to’ record contains a second record with the
+relationship_id set to ‘Maps to value’. For example, ICD10 <a
+href="https://athena.ohdsi.org/search-terms/terms/45581076">Z82.4</a>
+‘Family history of ischaemic heart disease and other diseases of the
+circulatory system’ has a ‘Maps to’ relationship to <a
+href="https://athena.ohdsi.org/search-terms/terms/4167217">4167217</a>
+‘Family history of clinical finding’ as well as a ‘Maps to value’ record
+to <a
+href="https://athena.ohdsi.org/search-terms/terms/134057">134057</a>
+‘Disorder of cardiovascular system’.
 </td>
 <td style="text-align:left;">
 Integer
@@ -5540,10 +6609,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 qualifier_concept_id
 </td>
 <td style="text-align:left;">
-This field contains all attributes specifying the clinical fact further, such as as degrees, severities, drug-drug interaction alerts etc.
+This field contains all attributes specifying the clinical fact further,
+such as as degrees, severities, drug-drug interaction alerts etc.
 </td>
 <td style="text-align:left;">
-Use your best judgement as to what Concepts to use here and if they are necessary to accurately represent the clinical record. There is no restriction on the domain of these Concepts, they just need to be Standard.
+Use your best judgement as to what Concepts to use here and if they are
+necessary to accurately represent the clinical record. There is no
+restriction on the domain of these Concepts, they just need to be
+Standard.
 </td>
 <td style="text-align:left;">
 integer
@@ -5568,10 +6641,15 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 unit_concept_id
 </td>
 <td style="text-align:left;">
-There is currently no recommended unit for individual observation concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit domain that best represents the unit as given in the source data.
+There is currently no recommended unit for individual observation
+concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in
+the Unit domain that best represents the unit as given in the source
+data.
 </td>
 <td style="text-align:left;">
-There is no standardization requirement for units associated with OBSERVATION_CONCEPT_IDs, however, it is the responsibility of the ETL to choose the most plausible unit.
+There is no standardization requirement for units associated with
+OBSERVATION_CONCEPT_IDs, however, it is the responsibility of the ETL to
+choose the most plausible unit.
 </td>
 <td style="text-align:left;">
 integer
@@ -5597,10 +6675,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with the observation record, e.g. the provider who ordered the test or the provider who recorded the result.
+The provider associated with the observation record, e.g. the provider
+who ordered the test or the provider who recorded the result.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record. For
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 integer
@@ -5628,7 +6710,15 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 The visit during which the Observation occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If an OBSERVATION_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the observation record. If an observation is related to a visit explicitly in the source data, it is possible that the result date of the Observation falls outside of the bounds of the Visit dates.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If an OBSERVATION_DATE occurs within the
+start and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the observation record. If an
+observation is related to a visit explicitly in the source data, it is
+possible that the result date of the Observation falls outside of the
+bounds of the Visit dates.
 </td>
 <td style="text-align:left;">
 integer
@@ -5653,7 +6743,10 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the Observation occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the Observation occurred. For
+example, if the Person was in the ICU at the time the VISIT_OCCURRENCE
+record would reflect the overall hospital stay and the VISIT_DETAIL
+record would reflect the ICU stay during the hospital visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -5681,10 +6774,13 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the Observation that occurred. For example, this could be an ICD10 or Read code.
+This field houses the verbatim value from the source data representing
+the Observation that occurred. For example, this could be an ICD10 or
+Read code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5708,10 +6804,19 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the OBSERVATION_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Observation necessary for a given analytic use case. Consider using OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the OBSERVATION_SOURCE_VALUE and may
+not necessarily be standard. This field is discouraged from use in
+analysis because it is not required to contain Standard Concepts that
+are used across the OHDSI community, and should only be used when
+Standard Concepts do not adequately represent the source detail for the
+Observation necessary for a given analytic use case. Consider using
+OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the OBSERVATION_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
+If the OBSERVATION_SOURCE_VALUE is coded in the source data using an
+OMOP supported vocabulary put the concept id representing the source
+value here.
 </td>
 <td style="text-align:left;">
 integer
@@ -5736,10 +6841,12 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the unit of the Observation that occurred.
+This field houses the verbatim value from the source data representing
+the unit of the Observation that occurred.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5763,10 +6870,12 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 qualifier_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the qualifier of the Observation that occurred.
+This field houses the verbatim value from the source data representing
+the qualifier of the Observation that occurred.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5790,10 +6899,17 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim result value of the Observation from the source data. Do not get confused with the Observation_source_value which captures source value of the observation mapped to observation_concept_id. This field is the observation result value from the source.
+This field houses the verbatim result value of the Observation from the
+source data. Do not get confused with the Observation_source_value which
+captures source value of the observation mapped to
+observation_concept_id. This field is the observation result value from
+the source.
 </td>
 <td style="text-align:left;">
-If the observation_source_value was a question, for example, or an observation that requires a result then this field is the answer/ result from the source data. Store the verbatim value that represents the result of the observation_source_value.
+If the observation_source_value was a question, for example, or an
+observation that requires a result then this field is the answer/ result
+from the source data. Store the verbatim value that represents the
+result of the observation_source_value.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5817,10 +6933,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_event_id
 </td>
 <td style="text-align:left;">
-If the Observation record is related to another record in the database, this field is the primary key of the linked record.
+If the Observation record is related to another record in the database,
+this field is the primary key of the linked record.
 </td>
 <td style="text-align:left;">
-Put the primary key of the linked record, if applicable, here. See the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#observation">ETL Conventions for the OBSERVATION</a> table for more details.
+Put the primary key of the linked record, if applicable, here. See the
+<a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#observation">ETL
+Conventions for the OBSERVATION</a> table for more details.
 </td>
 <td style="text-align:left;">
 integer
@@ -5844,10 +6964,13 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 obs_event_field_concept_id
 </td>
 <td style="text-align:left;">
-If the Observation record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from.
+If the Observation record is related to another record in the database,
+this field is the CONCEPT_ID that identifies which table the primary key
+of the linked record came from.
 </td>
 <td style="text-align:left;">
-Put the CONCEPT_ID that identifies which table and field the OBSERVATION_EVENT_ID came from.
+Put the CONCEPT_ID that identifies which table and field the
+OBSERVATION_EVENT_ID came from.
 </td>
 <td style="text-align:left;">
 integer
@@ -5873,7 +6996,11 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 <div id="death" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DEATH</h3>
 <p><strong>Table Description</strong></p>
-<p>The death domain contains the clinical event for how and when a Person dies. A person can have up to one record if the source system contains evidence about the Death, such as: Condition in an administrative claim, status of enrollment into a health plan, or explicit record in EHR data.</p>
+<p>The death domain contains the clinical event for how and when a
+Person dies. A person can have up to one record if the source system
+contains evidence about the Death, such as: Condition in an
+administrative claim, status of enrollment into a health plan, or
+explicit record in EHR data.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -5941,7 +7068,9 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 The date the person was deceased.
 </td>
 <td style="text-align:left;">
-If the precise date include day or month is not known or not allowed, December is used as the default month, and the last day of the month the default day.
+If the precise date include day or month is not known or not allowed,
+December is used as the default month, and the last day of the month the
+default day.
 </td>
 <td style="text-align:left;">
 date
@@ -5991,10 +7120,18 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 death_type_concept_id
 </td>
 <td style="text-align:left;">
-This is the provenance of the death record, i.e., where it came from. It is possible that an administrative claims database would source death information from a government file so do not assume the Death Type is the same as the Visit Type, etc.
+This is the provenance of the death record, i.e., where it came from. It
+is possible that an administrative claims database would source death
+information from a government file so do not assume the Death Type is
+the same as the Visit Type, etc.
 </td>
 <td style="text-align:left;">
-Use the type concept that be reflects the source of the death record. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Use the type concept that be reflects the source of the death record. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -6020,10 +7157,12 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 cause_concept_id
 </td>
 <td style="text-align:left;">
-This is the Standard Concept representing the Person’s cause of death, if available.
+This is the Standard Concept representing the Person’s cause of death,
+if available.
 </td>
 <td style="text-align:left;">
-There is no specified domain for this concept, just choose the Standard Concept Id that best represents the person’s cause of death.
+There is no specified domain for this concept, just choose the Standard
+Concept Id that best represents the person’s cause of death.
 </td>
 <td style="text-align:left;">
 integer
@@ -6076,7 +7215,8 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the cause of death was coded using a Vocabulary present in the OMOP Vocabularies put the CONCEPT_ID representing the cause of death here.
+If the cause of death was coded using a Vocabulary present in the OMOP
+Vocabularies put the CONCEPT_ID representing the cause of death here.
 </td>
 <td style="text-align:left;">
 integer
@@ -6102,17 +7242,38 @@ <h3 class="tabset tabset-pills">DEATH</h3>
 <div id="note" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">NOTE</h3>
 <p><strong>Table Description</strong></p>
-<p>The NOTE table captures unstructured information that was recorded by a provider about a patient in free text (in ASCII, or preferably in UTF8 format) notes on a given date. The type of note_text is CLOB or varchar(MAX) depending on RDBMS.</p>
+<p>The NOTE table captures unstructured information that was recorded by
+a provider about a patient in free text (in ASCII, or preferably in UTF8
+format) notes on a given date. The type of note_text is CLOB or
+varchar(MAX) depending on RDBMS.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>HL7/LOINC CDO is a standard for consistent naming of documents to support a range of use cases: retrieval, organization, display, and exchange. It guides the creation of LOINC codes for clinical notes. CDO annotates each document with 5 dimensions:</p>
+<p>HL7/LOINC CDO is a standard for consistent naming of documents to
+support a range of use cases: retrieval, organization, display, and
+exchange. It guides the creation of LOINC codes for clinical notes. CDO
+annotates each document with 5 dimensions:</p>
 <ul>
-<li><strong>Kind of Document</strong>: Characterizes the general structure of the document at a macro level (e.g. Anesthesia Consent)</li>
-<li><strong>Type of Service</strong>: Characterizes the kind of service or activity (e.g. evaluations, consultations, and summaries). The notion of time sequence, e.g., at the beginning (admission) at the end (discharge) is subsumed in this axis. Example: Discharge Teaching.</li>
-<li><strong>Setting</strong>: Setting is an extension of CMS’s definitions (e.g. Inpatient, Outpatient)</li>
-<li><strong>Subject Matter Domain (SMD)</strong>: Characterizes the subject matter domain of a note (e.g. Anesthesiology)</li>
-<li><strong>Role</strong>: Characterizes the training or professional level of the author of the document, but does not break down to specialty or subspecialty (e.g. Physician) Each combination of these 5 dimensions rolls up to a unique LOINC code.</li>
+<li><strong>Kind of Document</strong>: Characterizes the general
+structure of the document at a macro level (e.g. Anesthesia
+Consent)</li>
+<li><strong>Type of Service</strong>: Characterizes the kind of service
+or activity (e.g. evaluations, consultations, and summaries). The notion
+of time sequence, e.g., at the beginning (admission) at the end
+(discharge) is subsumed in this axis. Example: Discharge Teaching.</li>
+<li><strong>Setting</strong>: Setting is an extension of CMS’s
+definitions (e.g. Inpatient, Outpatient)</li>
+<li><strong>Subject Matter Domain (SMD)</strong>: Characterizes the
+subject matter domain of a note (e.g. Anesthesiology)</li>
+<li><strong>Role</strong>: Characterizes the training or professional
+level of the author of the document, but does not break down to
+specialty or subspecialty (e.g. Physician) Each combination of these 5
+dimensions rolls up to a unique LOINC code.</li>
 </ul>
-<p>According to CDO requirements, only 2 of the 5 dimensions are required to properly annotate a document; Kind of Document and any one of the other 4 dimensions. However, not all the permutations of the CDO dimensions will necessarily yield an existing LOINC code. Each of these dimensions are contained in the OMOP Vocabulary under the domain of ‘Meas Value’ with each dimension represented as a Concept Class.</p>
+<p>According to CDO requirements, only 2 of the 5 dimensions are
+required to properly annotate a document; Kind of Document and any one
+of the other 4 dimensions. However, not all the permutations of the CDO
+dimensions will necessarily yield an existing LOINC code. Each of these
+dimensions are contained in the OMOP Vocabulary under the domain of
+‘Meas Value’ with each dimension represented as a Concept Class.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -6258,7 +7419,12 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 The provenance of the note. Most likely this will be EHR.
 </td>
 <td style="text-align:left;">
-Put the source system of the note, as in EHR record. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Put the source system of the note, as in EHR record. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -6284,10 +7450,17 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 note_class_concept_id
 </td>
 <td style="text-align:left;">
-A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note.
+A Standard Concept Id representing the HL7 LOINC Document Type
+Vocabulary classification of the note.
 </td>
 <td style="text-align:left;">
-Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note).
+Map the note classification to a Standard Concept. For more information
+see the ETL Conventions in the description of the NOTE table. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. This Concept can alternatively be represented by concepts
+with the relationship ‘Kind of (LOINC)’ to <a
+href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a>
+(Note).
 </td>
 <td style="text-align:left;">
 integer
@@ -6367,7 +7540,10 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 This is the Concept representing the character encoding type.
 </td>
 <td style="text-align:left;">
-Put the Concept Id that represents the encoding character type here. Currently the only option is UTF-8 (<a href="https://athena.ohdsi.org/search-terms/terms/32678">32678</a>). It the note is encoded in any other type, like ASCII then put 0.
+Put the Concept Id that represents the encoding character type here.
+Currently the only option is UTF-8 (<a
+href="https://athena.ohdsi.org/search-terms/terms/32678">32678</a>). It
+the note is encoded in any other type, like ASCII then put 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -6395,7 +7571,9 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 The language of the note.
 </td>
 <td style="text-align:left;">
-Use Concepts that are descendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages).
+Use Concepts that are descendants of the concept <a
+href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a>
+(World Languages).
 </td>
 <td style="text-align:left;">
 integer
@@ -6528,7 +7706,8 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 note_event_id
 </td>
 <td style="text-align:left;">
-If the Note record is related to another record in the database, this field is the primary key of the linked record.
+If the Note record is related to another record in the database, this
+field is the primary key of the linked record.
 </td>
 <td style="text-align:left;">
 Put the primary key of the linked record, if applicable, here.
@@ -6555,10 +7734,13 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 note_event_field_concept_id
 </td>
 <td style="text-align:left;">
-If the Note record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from.
+If the Note record is related to another record in the database, this
+field is the CONCEPT_ID that identifies which table the primary key of
+the linked record came from.
 </td>
 <td style="text-align:left;">
-Put the CONCEPT_ID that identifies which table and field the NOTE_EVENT_ID came from.
+Put the CONCEPT_ID that identifies which table and field the
+NOTE_EVENT_ID came from.
 </td>
 <td style="text-align:left;">
 integer
@@ -6584,7 +7766,8 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 <div id="note_nlp" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <p><strong>Table Description</strong></p>
-<p>The NOTE_NLP table encodes all output of NLP on clinical notes. Each row represents a single extracted term from a note.</p>
+<p>The NOTE_NLP table encodes all output of NLP on clinical notes. Each
+row represents a single extracted term from a note.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -6677,7 +7860,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The SECTION_CONCEPT_ID should be used to represent the note section contained in the NOTE_NLP record. These concepts can be found as parts of document panels and are based on the type of note written, i.e. a discharge summary. These panels can be found as concepts with the relationship ‘Subsumes’ to CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
+The SECTION_CONCEPT_ID should be used to represent the note section
+contained in the NOTE_NLP record. These concepts can be found as parts
+of document panels and are based on the type of note written, i.e. a
+discharge summary. These panels can be found as concepts with the
+relationship ‘Subsumes’ to CONCEPT_ID <a
+href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -6834,7 +8022,8 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Name and version of the NLP system that extracted the term. Useful for data provenance.
+Name and version of the NLP system that extracted the term. Useful for
+data provenance.
 </td>
 <td style="text-align:left;">
 varchar(250)
@@ -6912,7 +8101,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Term_exists is defined as a flag that indicates if the patient actually has or had the condition. Any of the following modifiers would make Term_exists false: Negation = true Subject = [anything other than the patient] Conditional = true/li&gt; Rule_out = true Uncertain = very low certainty or any lower certainties A complete lack of modifiers would make Term_exists true.
+Term_exists is defined as a flag that indicates if the patient actually
+has or had the condition. Any of the following modifiers would make
+Term_exists false: Negation = true Subject = [anything other than the
+patient] Conditional = true/li&gt; Rule_out = true Uncertain = very low
+certainty or any lower certainties A complete lack of modifiers would
+make Term_exists true.
 </td>
 <td style="text-align:left;">
 varchar(1)
@@ -6938,7 +8132,9 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Term_temporal is to indicate if a condition is present or just in the past. The following would be past:<br><br> - History = true - Concept_date = anything before the time of the report
+Term_temporal is to indicate if a condition is present or just in the
+past. The following would be past:<br><br> - History = true -
+Concept_date = anything before the time of the report
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -6964,7 +8160,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-For the modifiers that are there, they would have to have these values:<br><br> - Negation = false - Subject = patient - Conditional = false - Rule_out = false - Uncertain = true or high or moderate or even low (could argue about low). Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers.
+For the modifiers that are there, they would have to have these
+values:<br><br> - Negation = false - Subject = patient - Conditional =
+false - Rule_out = false - Uncertain = true or high or moderate or even
+low (could argue about low). Term_modifiers will concatenate all
+modifiers for different types of entities (conditions, drugs, labs etc)
+into one string. Lab values will be saved as one of the modifiers.
 </td>
 <td style="text-align:left;">
 varchar(2000)
@@ -6989,9 +8190,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <div id="specimen" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <p><strong>Table Description</strong></p>
-<p>The specimen domain contains the records identifying biological samples from a person.</p>
+<p>The specimen domain contains the records identifying biological
+samples from a person.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Anatomic site is coded at the most specific level of granularity possible, such that higher level classifications can be derived using the Standardized Vocabularies.</p>
+<p>Anatomic site is coded at the most specific level of granularity
+possible, such that higher level classifications can be derived using
+the Standardized Vocabularies.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7085,7 +8289,10 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the specimen domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the
+specimen domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -7112,7 +8319,12 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Put the source of the specimen record, as in an EHR system. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Put the source of the specimen record, as in an EHR system. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -7218,7 +8430,9 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 The unit for the quantity of the specimen.
 </td>
 <td style="text-align:left;">
-Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -7246,7 +8460,11 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 This is the site on the body where the specimen is from.
 </td>
 <td style="text-align:left;">
-Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec Anatomic Site domain. This should be coded at the lowest level of granularity <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Spec+Anatomic+Site&amp;conceptClass=Body+Structure&amp;page=4&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec
+Anatomic Site domain. This should be coded at the lowest level of
+granularity <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Spec+Anatomic+Site&amp;conceptClass=Body+Structure&amp;page=4&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -7350,7 +8568,8 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This unit for the quantity of the specimen, as represented in the source.
+This unit for the quantity of the specimen, as represented in the
+source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -7376,7 +8595,8 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is the site on the body where the specimen was taken from, as represented in the source.
+This is the site on the body where the specimen was taken from, as
+represented in the source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -7426,9 +8646,24 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <div id="fact_relationship" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">FACT_RELATIONSHIP</h3>
 <p><strong>Table Description</strong></p>
-<p>The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains. Examples of Fact Relationships include: <a href="https://athena.ohdsi.org/search-terms/terms?domain=Relationship&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Person relationships</a> (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).</p>
+<p>The FACT_RELATIONSHIP table contains records about the relationships
+between facts stored as records in any table of the CDM. Relationships
+can be defined between facts from the same domain, or different domains.
+Examples of Fact Relationships include: <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Relationship&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Person
+relationships</a> (parent-child), care site relationships (hierarchical
+organizational structure of facilities within a health system),
+indication relationship (between drug exposures and associated
+conditions), usage relationships (of devices during the course of an
+associated procedure), or facts derived from one another (measurements
+derived from an associated specimen).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>All relationships are directional, and each relationship is represented twice symmetrically within the FACT_RELATIONSHIP table. For example, two persons if person_id = 1 is the mother of person_id = 2 two records are in the FACT_RELATIONSHIP table (all strings in fact concept_id records in the Concept table: - Person, 1, Person, 2, parent of - Person, 2, Person, 1, child of</p>
+<p>All relationships are directional, and each relationship is
+represented twice symmetrically within the FACT_RELATIONSHIP table. For
+example, two persons if person_id = 1 is the mother of person_id = 2 two
+records are in the FACT_RELATIONSHIP table (all strings in fact
+concept_id records in the Concept table: - Person, 1, Person, 2, parent
+of - Person, 2, Person, 1, child of</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7599,11 +8834,20 @@ <h2><strong>Health System Data Tables</strong></h2>
 <div id="location" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">LOCATION</h3>
 <p><strong>Table Description</strong></p>
-<p>The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites.</p>
+<p>The LOCATION table represents a generic way to capture physical
+location or address information of Persons and Care Sites.</p>
 <p><strong>User Guide</strong></p>
-<p>The current iteration of the LOCATION table is US centric. Until a major release to correct this, certain fields can be used to represent different international values. <br><br> - STATE can also be used for province or district<br>- ZIP is also the postal code or postcode <br>- COUNTY can also be used to represent region</p>
+<p>The current iteration of the LOCATION table is US centric. Until a
+major release to correct this, certain fields can be used to represent
+different international values. <br><br> - STATE can also be used for
+province or district<br>- ZIP is also the postal code or postcode <br>-
+COUNTY can also be used to represent region</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Each address or Location is unique and is present only once in the table. Locations do not contain names, such as the name of a hospital. In order to construct a full address that can be used in the postal service, the address information from the Location needs to be combined with information from the Care Site.</p>
+<p>Each address or Location is unique and is present only once in the
+table. Locations do not contain names, such as the name of a hospital.
+In order to construct a full address that can be used in the postal
+service, the address information from the Location needs to be combined
+with information from the Care Site.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7645,7 +8889,8 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 The unique key given to a unique Location.
 </td>
 <td style="text-align:left;">
-Each instance of a Location in the source data should be assigned this unique key.
+Each instance of a Location in the source data should be assigned this
+unique key.
 </td>
 <td style="text-align:left;">
 integer
@@ -7773,7 +9018,12 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Zip codes are handled as strings of up to 9 characters length. For US addresses, these represent either a 3-digit abbreviated Zip code as provided by many sources for patient protection reasons, the full 5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons analytical methods should expect and utilize only the first 3 digits. For international addresses, different rules apply.
+Zip codes are handled as strings of up to 9 characters length. For US
+addresses, these represent either a 3-digit abbreviated Zip code as
+provided by many sources for patient protection reasons, the full
+5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons
+analytical methods should expect and utilize only the first 3 digits.
+For international addresses, different rules apply.
 </td>
 <td style="text-align:left;">
 varchar(9)
@@ -7824,7 +9074,8 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Put the verbatim value for the location here, as it shows up in the source.
+Put the verbatim value for the location here, as it shows up in the
+source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -7848,7 +9099,9 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 country_concept_id
 </td>
 <td style="text-align:left;">
-The Concept Id representing the country. Values should conform to the <a href="https://athena.ohdsi.org/search-terms/terms?domain=Geography&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=&amp;boosts">Geography</a> domain.
+The Concept Id representing the country. Values should conform to the <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Geography&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=&amp;boosts">Geography</a>
+domain.
 </td>
 <td style="text-align:left;">
 </td>
@@ -7954,9 +9207,23 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 <div id="care_site" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <p><strong>Table Description</strong></p>
-<p>The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).</p>
+<p>The CARE_SITE table contains a list of uniquely identified
+institutional (physical or organizational) units where healthcare
+delivery is practiced (offices, wards, hospitals, clinics, etc.).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Care site is a unique combination of location_id and place_of_service_source_value. Care site does not take into account the provider (human) information such a specialty. Many source data do not make a distinction between individual and institutional providers. The CARE_SITE table contains the institutional providers. If the source, instead of uniquely identifying individual Care Sites, only provides limited information such as Place of Service, generic or “pooled” Care Site records are listed in the CARE_SITE table. There can be hierarchical and business relationships between Care Sites. For example, wards can belong to clinics or departments, which can in turn belong to hospitals, which in turn can belong to hospital systems, which in turn can belong to HMOs.The relationships between Care Sites are defined in the FACT_RELATIONSHIP table.</p>
+<p>Care site is a unique combination of location_id and
+place_of_service_source_value. Care site does not take into account the
+provider (human) information such a specialty. Many source data do not
+make a distinction between individual and institutional providers. The
+CARE_SITE table contains the institutional providers. If the source,
+instead of uniquely identifying individual Care Sites, only provides
+limited information such as Place of Service, generic or “pooled” Care
+Site records are listed in the CARE_SITE table. There can be
+hierarchical and business relationships between Care Sites. For example,
+wards can belong to clinics or departments, which can in turn belong to
+hospitals, which in turn can belong to hospital systems, which in turn
+can belong to HMOs.The relationships between Care Sites are defined in
+the FACT_RELATIONSHIP table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7997,7 +9264,9 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Assign an ID to each combination of a location and nature of the site - the latter could be the Place of Service, name or another characteristic in your source data.
+Assign an ID to each combination of a location and nature of the site -
+the latter could be the Place of Service, name or another characteristic
+in your source data.
 </td>
 <td style="text-align:left;">
 integer
@@ -8047,10 +9316,18 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 place_of_service_concept_id
 </td>
 <td style="text-align:left;">
-This is a high-level way of characterizing a Care Site. Typically, however, Care Sites can provide care in multiple settings (inpatient, outpatient, etc.) and this granularity should be reflected in the visit.
+This is a high-level way of characterizing a Care Site. Typically,
+however, Care Sites can provide care in multiple settings (inpatient,
+outpatient, etc.) and this granularity should be reflected in the visit.
 </td>
 <td style="text-align:left;">
-Choose the concept in the visit domain that best represents the setting in which healthcare is provided in the Care Site. If most visits in a Care Site are Inpatient, then the place_of_service_concept_id should represent Inpatient. If information is present about a unique Care Site (e.g. Pharmacy) then a Care Site record should be created. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the concept in the visit domain that best represents the setting
+in which healthcare is provided in the Care Site. If most visits in a
+Care Site are Inpatient, then the place_of_service_concept_id should
+represent Inpatient. If information is present about a unique Care Site
+(e.g. Pharmacy) then a Care Site record should be created. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8075,7 +9352,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 location_id
 </td>
 <td style="text-align:left;">
-The location_id from the LOCATION table representing the physical location of the care_site.
+The location_id from the LOCATION table representing the physical
+location of the care_site.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8102,7 +9380,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 care_site_source_value
 </td>
 <td style="text-align:left;">
-The identifier of the care_site as it appears in the source data. This could be an identifier separate from the name of the care_site.
+The identifier of the care_site as it appears in the source data. This
+could be an identifier separate from the name of the care_site.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8130,7 +9409,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Put the place of service of the care_site as it appears in the source data.
+Put the place of service of the care_site as it appears in the source
+data.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8155,9 +9435,16 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <div id="provider" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PROVIDER</h3>
 <p><strong>Table Description</strong></p>
-<p>The PROVIDER table contains a list of uniquely identified healthcare providers. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc.</p>
+<p>The PROVIDER table contains a list of uniquely identified healthcare
+providers. These are individuals providing hands-on healthcare to
+patients, such as physicians, nurses, midwives, physical therapists
+etc.</p>
 <p><strong>User Guide</strong></p>
-<p>Many sources do not make a distinction between individual and institutional providers. The PROVIDER table contains the individual providers. If the source, instead of uniquely identifying individual providers, only provides limited information such as specialty, generic or ‘pooled’ Provider records are listed in the PROVIDER table.</p>
+<p>Many sources do not make a distinction between individual and
+institutional providers. The PROVIDER table contains the individual
+providers. If the source, instead of uniquely identifying individual
+providers, only provides limited information such as specialty, generic
+or ‘pooled’ Provider records are listed in the PROVIDER table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -8196,10 +9483,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently.
+It is assumed that every provider with a different unique identifier is
+in fact a different person and should be treated independently.
 </td>
 <td style="text-align:left;">
-This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number.
+This identifier can be the original id from the source data provided it
+is an integer, otherwise it can be an autogenerated number.
 </td>
 <td style="text-align:left;">
 integer
@@ -8225,7 +9514,9 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This field is not necessary as it is not necessary to have the actual identity of the Provider. Rather, the idea is to uniquely and anonymously identify providers of care across the database.
+This field is not necessary as it is not necessary to have the actual
+identity of the Provider. Rather, the idea is to uniquely and
+anonymously identify providers of care across the database.
 </td>
 <td style="text-align:left;">
 varchar(255)
@@ -8249,7 +9540,8 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 npi
 </td>
 <td style="text-align:left;">
-This is the National Provider Number issued to health care providers in the US by the Centers for Medicare and Medicaid Services (CMS).
+This is the National Provider Number issued to health care providers in
+the US by the Centers for Medicare and Medicaid Services (CMS).
 </td>
 <td style="text-align:left;">
 </td>
@@ -8275,7 +9567,8 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 dea
 </td>
 <td style="text-align:left;">
-This is the identifier issued by the DEA, a US federal agency, that allows a provider to write prescriptions for controlled substances.
+This is the identifier issued by the DEA, a US federal agency, that
+allows a provider to write prescriptions for controlled substances.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8301,10 +9594,20 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 specialty_concept_id
 </td>
 <td style="text-align:left;">
-This field either represents the most common specialty that occurs in the data or the most specific concept that represents all specialties listed, should the provider have more than one. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.
+This field either represents the most common specialty that occurs in
+the data or the most specific concept that represents all specialties
+listed, should the provider have more than one. This includes physician
+specialties such as internal medicine, emergency medicine, etc. and
+allied health professionals such as nurses, midwives, and pharmacists.
 </td>
 <td style="text-align:left;">
-If a Provider has more than one Specialty, there are two options: 1. Choose a concept_id which is a common ancestor to the multiple specialties, or, 2. Choose the specialty that occurs most often for the provider. Concepts in this field should be Standard with a domain of Provider. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Provider&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If a Provider has more than one Specialty, there are two options: 1.
+Choose a concept_id which is a common ancestor to the multiple
+specialties, or, 2. Choose the specialty that occurs most often for the
+provider. Concepts in this field should be Standard with a domain of
+Provider. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Provider&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8329,10 +9632,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-This is the CARE_SITE_ID for the location that the provider primarily practices in.
+This is the CARE_SITE_ID for the location that the provider primarily
+practices in.
 </td>
 <td style="text-align:left;">
-If a Provider has more than one Care Site, the main or most often exerted CARE_SITE_ID should be recorded.
+If a Provider has more than one Care Site, the main or most often
+exerted CARE_SITE_ID should be recorded.
 </td>
 <td style="text-align:left;">
 integer
@@ -8382,10 +9687,14 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 gender_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the recorded gender of the provider in the source data.
+This field represents the recorded gender of the provider in the source
+data.
 </td>
 <td style="text-align:left;">
-If given, put a concept from the gender domain representing the recorded gender of the provider. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If given, put a concept from the gender domain representing the recorded
+gender of the provider. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8411,10 +9720,13 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 provider_source_value
 </td>
 <td style="text-align:left;">
-Use this field to link back to providers in the source data. This is typically used for error checking of ETL logic.
+Use this field to link back to providers in the source data. This is
+typically used for error checking of ETL logic.
 </td>
 <td style="text-align:left;">
-Some use cases require the ability to link back to providers in the source data. This field allows for the storing of the provider identifier as it appears in the source.
+Some use cases require the ability to link back to providers in the
+source data. This field allows for the storing of the provider
+identifier as it appears in the source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8438,10 +9750,15 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 specialty_source_value
 </td>
 <td style="text-align:left;">
-This is the kind of provider or specialty as it appears in the source data. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.
+This is the kind of provider or specialty as it appears in the source
+data. This includes physician specialties such as internal medicine,
+emergency medicine, etc. and allied health professionals such as nurses,
+midwives, and pharmacists.
 </td>
 <td style="text-align:left;">
-Put the kind of provider as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.
+Put the kind of provider as it appears in the source data. This field is
+up to the discretion of the ETL-er as to whether this should be the
+coded value from the source or the text description of the lookup value.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8465,10 +9782,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 specialty_source_concept_id
 </td>
 <td style="text-align:left;">
-This is often zero as many sites use proprietary codes to store physician speciality.
+This is often zero as many sites use proprietary codes to store
+physician speciality.
 </td>
 <td style="text-align:left;">
-If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here.
+If the source data codes provider specialty in an OMOP supported
+vocabulary store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8496,7 +9815,9 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 This is provider’s gender as it appears in the source data.
 </td>
 <td style="text-align:left;">
-Put the provider’s gender as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.
+Put the provider’s gender as it appears in the source data. This field
+is up to the discretion of the ETL-er as to whether this should be the
+coded value from the source or the text description of the lookup value.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8520,10 +9841,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 gender_source_concept_id
 </td>
 <td style="text-align:left;">
-This is often zero as many sites use proprietary codes to store provider gender.
+This is often zero as many sites use proprietary codes to store provider
+gender.
 </td>
 <td style="text-align:left;">
-If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here.
+If the source data codes provider gender in an OMOP supported vocabulary
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8552,9 +9875,25 @@ <h2><strong>Health Economics Data Tables</strong></h2>
 <div id="payer_plan_period" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <p><strong>Table Description</strong></p>
-<p>The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.</p>
+<p>The PAYER_PLAN_PERIOD table captures details of the period of time
+that a Person is continuously enrolled under a specific health Plan
+benefit structure from a given Payer. Each Person receiving healthcare
+is typically covered by a health benefit plan, which pays for (fully or
+partially), or directly provides, the care. These benefit plans are
+provided by payers, such as health insurances or state or government
+agencies. In each plan the details of the health benefits are defined
+for the Person or her family, and the health benefit Plan might change
+over time typically with increasing utilization (reaching certain cost
+thresholds such as deductibles), plan availability and purchasing
+choices of the Person. The unique combinations of Payer organizations,
+health benefit Plans and time periods in which they are valid for a
+Person are recorded in this table.</p>
 <p><strong>User Guide</strong></p>
-<p>A Person can have multiple, overlapping, Payer_Plan_Periods in this table. For example, medical and drug coverage in the US can be represented by two Payer_Plan_Periods. The details of the benefit structure of the Plan is rarely known, the idea is just to identify that the Plans are different.</p>
+<p>A Person can have multiple, overlapping, Payer_Plan_Periods in this
+table. For example, medical and drug coverage in the US can be
+represented by two Payer_Plan_Periods. The details of the benefit
+structure of the Plan is rarely known, the idea is just to identify that
+the Plans are different.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -8593,7 +9932,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 payer_plan_period_id
 </td>
 <td style="text-align:left;">
-A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time.
+A unique identifier for each unique combination of a Person, Payer,
+Plan, and Period of time.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8622,7 +9962,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 The Person covered by the Plan.
 </td>
 <td style="text-align:left;">
-A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records
+A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD
+records
 </td>
 <td style="text-align:left;">
 integer
@@ -8699,10 +10040,17 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 payer_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the organization who reimburses the provider which administers care to the Person.
+This field represents the organization who reimburses the provider which
+administers care to the Person.
 </td>
 <td style="text-align:left;">
-Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the Payer directly to a standard CONCEPT_ID. If one does not exists
+please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. The point is to stratify on
+this information and identify if Persons have the same payer, though the
+name of the Payer is not necessary. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8755,7 +10103,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the Payer in an OMOP supported vocabulary store
+the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8780,10 +10129,17 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 plan_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the specific health benefit Plan the Person is enrolled in.
+This field represents the specific health benefit Plan the Person is
+enrolled in.
 </td>
 <td style="text-align:left;">
-Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Plan&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the Plan directly to a standard CONCEPT_ID. If one does not exists
+please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. The point is to stratify on
+this information and identify if Persons have the same health benefit
+Plan though the name of the Plan is not necessary. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Plan&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8808,7 +10164,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 plan_source_value
 </td>
 <td style="text-align:left;">
-This is the health benefit Plan of the Person as it appears in the source data.
+This is the health benefit Plan of the Person as it appears in the
+source data.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8836,7 +10193,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the Plan in an OMOP supported vocabulary store
+the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8861,10 +10219,18 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 sponsor_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan.
+This field represents the sponsor of the Plan who finances the Plan.
+This includes self-insured, small group health plan and large group
+health plan.
 </td>
 <td style="text-align:left;">
-Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the sponsor directly to a standard CONCEPT_ID. If one does not
+exists please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. The point is to stratify on
+this information and identify if Persons have the same sponsor though
+the name of the sponsor is not necessary. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8917,7 +10283,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the sponsor in an OMOP supported vocabulary
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8942,10 +10309,12 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 family_source_value
 </td>
 <td style="text-align:left;">
-The common identifier for all people (often a family) that covered by the same policy.
+The common identifier for all people (often a family) that covered by
+the same policy.
 </td>
 <td style="text-align:left;">
-Often these are the common digits of the enrollment id of the policy members.
+Often these are the common digits of the enrollment id of the policy
+members.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8972,7 +10341,11 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 This field represents the reason the Person left the Plan, if known.
 </td>
 <td style="text-align:left;">
-Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the stop reason directly to a standard CONCEPT_ID. If one does not
+exists please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -9025,7 +10398,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the stop reason in an OMOP supported vocabulary
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -9051,12 +10425,36 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <div id="cost" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">COST</h3>
 <p><strong>Table Description</strong></p>
-<p>The COST table captures records containing the cost of any medical event recorded in one of the OMOP clinical event tables such as DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL, DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT.</p>
-<p>Each record in the cost table account for the amount of money transacted for the clinical event. So, the COST table may be used to represent both receivables (charges) and payments (paid), each transaction type represented by its COST_CONCEPT_ID. The COST_TYPE_CONCEPT_ID field will use concepts in the Standardized Vocabularies to designate the source (provenance) of the cost data. A reference to the health plan information in the PAYER_PLAN_PERIOD table is stored in the record for information used for the adjudication system to determine the persons benefit for the clinical event.</p>
+<p>The COST table captures records containing the cost of any medical
+event recorded in one of the OMOP clinical event tables such as
+DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL,
+DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT.</p>
+<p>Each record in the cost table account for the amount of money
+transacted for the clinical event. So, the COST table may be used to
+represent both receivables (charges) and payments (paid), each
+transaction type represented by its COST_CONCEPT_ID. The
+COST_TYPE_CONCEPT_ID field will use concepts in the Standardized
+Vocabularies to designate the source (provenance) of the cost data. A
+reference to the health plan information in the PAYER_PLAN_PERIOD table
+is stored in the record for information used for the adjudication system
+to determine the persons benefit for the clinical event.</p>
 <p><strong>User Guide</strong></p>
-<p>When dealing with summary costs, the cost of the goods or services the provider provides is often not known directly, but derived from the hospital charges multiplied by an average cost-to-charge ratio.</p>
+<p>When dealing with summary costs, the cost of the goods or services
+the provider provides is often not known directly, but derived from the
+hospital charges multiplied by an average cost-to-charge ratio.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. Therefore, it is possible for one procedure to have multiple cost records for each payer, but typically it contains one or no record per entity. Payer reimbursement cost records will be identified by using the PAYER_PLAN_ID field. Drug costs are composed of ingredient cost (the amount charged by the wholesale distributor or manufacturer), the dispensing fee (the amount charged by the pharmacy and the sales tax).</p>
+<p>One cost record is generated for each response by a payer. In a
+claims databases, the payment and payment terms reported by the payer
+for the goods or services billed will generate one cost record. If the
+source data has payment information for more than one payer
+(i.e. primary insurance and secondary insurance payment for one entity),
+then a cost record is created for each reporting payer. Therefore, it is
+possible for one procedure to have multiple cost records for each payer,
+but typically it contains one or no record per entity. Payer
+reimbursement cost records will be identified by using the PAYER_PLAN_ID
+field. Drug costs are composed of ingredient cost (the amount charged by
+the wholesale distributor or manufacturer), the dispensing fee (the
+amount charged by the pharmacy and the sales tax).</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -9574,7 +10972,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 revenue_code_source_value
 </td>
 <td style="text-align:left;">
-Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system.
+Revenue codes are a method to charge for a class of procedures and
+conditions in the U.S. hospital system.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9626,7 +11025,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 drg_source_value
 </td>
 <td style="text-align:left;">
-Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups.
+Diagnosis Related Groups are US codes used to classify hospital cases
+into one of approximately 500 groups.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9656,9 +11056,15 @@ <h2><strong>Standardized Derived Elements</strong></h2>
 <div id="drug_era" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <p><strong>Table Description</strong></p>
-<p>A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras.</p>
+<p>A Drug Era is defined as a span of time when the Person is assumed to
+be exposed to a particular active ingredient. A Drug Era is not the same
+as a Drug Exposure: Exposures are individual records corresponding to
+the source when Drug was delivered to the Person, while successive
+periods of Drug Exposures are combined under certain rules to produce
+continuous Drug Eras.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>The SQL script for generating DRUG_ERA records can be found <a href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#drug_eras">here</a>.</p>
+<p>The SQL script for generating DRUG_ERA records can be found <a
+href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#drug_eras">here</a>.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -9778,7 +11184,8 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure.
+The Drug Era Start Date is the start date of the first Drug Exposure for
+a given ingredient, with at least 31 days since the previous exposure.
 </td>
 <td style="text-align:left;">
 date
@@ -9804,7 +11211,19 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules: For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information. For Procedure Drugs, usually the drug is administered on a single date (i.e., the administration date). A standard Persistence Window of 30 days (gap, slack) is permitted between two subsequent such extrapolated DRUG_EXPOSURE records to be considered to be merged into a single Drug Era.
+The Drug Era End Date is the end date of the last Drug Exposure. The End
+Date of each Drug Exposure is either taken from the field
+drug_exposure_end_date or, as it is typically not available, inferred
+using the following rules: For pharmacy prescription data, the date when
+the drug was dispensed plus the number of days of supply are used to
+extrapolate the End Date for the Drug Exposure. Depending on the
+country-specific healthcare system, this supply information is either
+explicitly provided in the day_supply field or inferred from package
+size or similar information. For Procedure Drugs, usually the drug is
+administered on a single date (i.e., the administration date). A
+standard Persistence Window of 30 days (gap, slack) is permitted between
+two subsequent such extrapolated DRUG_EXPOSURE records to be considered
+to be merged into a single Drug Era.
 </td>
 <td style="text-align:left;">
 date
@@ -9855,7 +11274,16 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The Gap Days determine how many total drug-free days are observed between all Drug Exposure events that contribute to a DRUG_ERA record. It is assumed that the drugs are “not stockpiled” by the patient, i.e. that if a new drug prescription or refill is observed (a new DRUG_EXPOSURE record is written), the remaining supply from the previous events is abandoned. The difference between Persistence Window and Gap Days is that the former is the maximum drug-free time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual drug-free days for the given Drug Era under the above assumption of non-stockpiling.
+The Gap Days determine how many total drug-free days are observed
+between all Drug Exposure events that contribute to a DRUG_ERA record.
+It is assumed that the drugs are “not stockpiled” by the patient,
+i.e. that if a new drug prescription or refill is observed (a new
+DRUG_EXPOSURE record is written), the remaining supply from the previous
+events is abandoned. The difference between Persistence Window and Gap
+Days is that the former is the maximum drug-free time allowed between
+two subsequent DRUG_EXPOSURE records, while the latter is the sum of
+actual drug-free days for the given Drug Era under the above assumption
+of non-stockpiling.
 </td>
 <td style="text-align:left;">
 integer
@@ -9880,9 +11308,15 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <div id="dose_era" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 <p><strong>Table Description</strong></p>
-<p>A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.</p>
+<p>A Dose Era is defined as a span of time when the Person is assumed to
+be exposed to a constant dose of a specific active ingredient.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Dose Eras will be derived from records in the DRUG_EXPOSURE table and the Dose information from the DRUG_STRENGTH table using a standardized algorithm. Dose Form information is not taken into account. So, if the patient changes between different formulations, or different manufacturers with the same formulation, the Dose Era is still spanning the entire time of exposure to the Ingredient.</p>
+<p>Dose Eras will be derived from records in the DRUG_EXPOSURE table and
+the Dose information from the DRUG_STRENGTH table using a standardized
+algorithm. Dose Form information is not taken into account. So, if the
+patient changes between different formulations, or different
+manufacturers with the same formulation, the Dose Era is still spanning
+the entire time of exposure to the Ingredient.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10054,7 +11488,8 @@ <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 dose_era_start_date
 </td>
 <td style="text-align:left;">
-The date the Person started on the specific dosage, with at least 31 days since any prior exposure.
+The date the Person started on the specific dosage, with at least 31
+days since any prior exposure.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10082,7 +11517,9 @@ <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The date the Person was no longer exposed to the dosage of the specific drug ingredient. An era is ended if there are 31 days or more between dosage records.
+The date the Person was no longer exposed to the dosage of the specific
+drug ingredient. An era is ended if there are 31 days or more between
+dosage records.
 </td>
 <td style="text-align:left;">
 date
@@ -10107,13 +11544,39 @@ <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 <div id="condition_era" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 <p><strong>Table Description</strong></p>
-<p>A Condition Era is defined as a span of time when the Person is assumed to have a given condition. Similar to Drug Eras, Condition Eras are chronological periods of Condition Occurrence. Combining individual Condition Occurrences into a single Condition Era serves two purposes:</p>
+<p>A Condition Era is defined as a span of time when the Person is
+assumed to have a given condition. Similar to Drug Eras, Condition Eras
+are chronological periods of Condition Occurrence. Combining individual
+Condition Occurrences into a single Condition Era serves two
+purposes:</p>
 <ul>
-<li>It allows aggregation of chronic conditions that require frequent ongoing care, instead of treating each Condition Occurrence as an independent event.</li>
-<li>It allows aggregation of multiple, closely timed doctor visits for the same Condition to avoid double-counting the Condition Occurrences. For example, consider a Person who visits her Primary Care Physician (PCP) and who is referred to a specialist. At a later time, the Person visits the specialist, who confirms the PCP’s original diagnosis and provides the appropriate treatment to resolve the condition. These two independent doctor visits should be aggregated into one Condition Era.</li>
+<li>It allows aggregation of chronic conditions that require frequent
+ongoing care, instead of treating each Condition Occurrence as an
+independent event.</li>
+<li>It allows aggregation of multiple, closely timed doctor visits for
+the same Condition to avoid double-counting the Condition Occurrences.
+For example, consider a Person who visits her Primary Care Physician
+(PCP) and who is referred to a specialist. At a later time, the Person
+visits the specialist, who confirms the PCP’s original diagnosis and
+provides the appropriate treatment to resolve the condition. These two
+independent doctor visits should be aggregated into one Condition
+Era.</li>
 </ul>
 <p><strong>ETL Conventions</strong></p>
-<p>Each Condition Era corresponds to one or many Condition Occurrence records that form a continuous interval. The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers. The SQl Script for generating CONDITION_ERA records can be found <a href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#condition_eras">here</a> The Condition Era Start Date is the start date of the first Condition Occurrence. The Condition Era End Date is the end date of the last Condition Occurrence. Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurrence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date.</p>
+<p>Each Condition Era corresponds to one or many Condition Occurrence
+records that form a continuous interval. The condition_concept_id field
+contains Concepts that are identical to those of the
+CONDITION_OCCURRENCE table records that make up the Condition Era. In
+contrast to Drug Eras, Condition Eras are not aggregated to contain
+Conditions of different hierarchical layers. The SQl Script for
+generating CONDITION_ERA records can be found <a
+href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#condition_eras">here</a>
+The Condition Era Start Date is the start date of the first Condition
+Occurrence. The Condition Era End Date is the end date of the last
+Condition Occurrence. Condition Eras are built with a Persistence Window
+of 30 days, meaning, if no occurrence of the same condition_concept_id
+happens within 30 days of any one occurrence, it will be considered the
+condition_era_end_date.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10231,7 +11694,10 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 condition_era_start_date
 </td>
 <td style="text-align:left;">
-The start date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the start date of the very first chronologically recorded instance of the condition with at least 31 days since any prior record of the same Condition.
+The start date for the Condition Era constructed from the individual
+instances of Condition Occurrences. It is the start date of the very
+first chronologically recorded instance of the condition with at least
+31 days since any prior record of the same Condition.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10257,7 +11723,9 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 condition_era_end_date
 </td>
 <td style="text-align:left;">
-The end date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the end date of the final continuously recorded instance of the Condition.
+The end date for the Condition Era constructed from the individual
+instances of Condition Occurrences. It is the end date of the final
+continuously recorded instance of the Condition.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10283,7 +11751,8 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 condition_occurrence_count
 </td>
 <td style="text-align:left;">
-The number of individual Condition Occurrences used to construct the condition era.
+The number of individual Condition Occurrences used to construct the
+condition era.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10310,9 +11779,21 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 <div id="episode" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">EPISODE</h3>
 <p><strong>Table Description</strong></p>
-<p>The EPISODE table aggregates lower-level clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) into a higher-level abstraction representing clinically and analytically relevant disease phases,outcomes and treatments. The EPISODE_EVENT table connects qualifying clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry. For example cancers including their development over time, their treatment, and final resolution.</p>
+<p>The EPISODE table aggregates lower-level clinical events
+(VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE)
+into a higher-level abstraction representing clinically and analytically
+relevant disease phases,outcomes and treatments. The EPISODE_EVENT table
+connects qualifying clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE,
+PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry.
+For example cancers including their development over time, their
+treatment, and final resolution.</p>
 <p><strong>User Guide</strong></p>
-<p>Valid Episode Concepts belong to the ‘Episode’ domain. For cancer episodes please see [article], for non-cancer episodes please see [article]. If your source data does not have all episodes that are relevant to the therapeutic area, write only those you can easily derive from the data. It is understood that that table is not currently expected to be comprehensive.</p>
+<p>Valid Episode Concepts belong to the ‘Episode’ domain. For cancer
+episodes please see [article], for non-cancer episodes please see
+[article]. If your source data does not have all episodes that are
+relevant to the therapeutic area, write only those you can easily derive
+from the data. It is understood that that table is not currently
+expected to be comprehensive.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10404,10 +11885,15 @@ <h3 class="tabset tabset-pills">EPISODE</h3>
 episode_concept_id
 </td>
 <td style="text-align:left;">
-The EPISODE_CONCEPT_ID represents the kind abstraction related to the disease phase, outcome or treatment.
+The EPISODE_CONCEPT_ID represents the kind abstraction related to the
+disease phase, outcome or treatment.
 </td>
 <td style="text-align:left;">
-Choose a concept in the Episode domain that best represents the ongoing disease phase, outcome, or treatment. Please see [article] for cancers and [article] for non-cancers describing how these are defined. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Episode&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+Choose a concept in the Episode domain that best represents the ongoing
+disease phase, outcome, or treatment. Please see [article] for cancers
+and [article] for non-cancers describing how these are defined. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Episode&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -10539,10 +12025,13 @@ <h3 class="tabset tabset-pills">EPISODE</h3>
 episode_parent_id
 </td>
 <td style="text-align:left;">
-Use this field to find the Episode that subsumes the given Episode record. This is used in the case that an Episode are nested into each other.
+Use this field to find the Episode that subsumes the given Episode
+record. This is used in the case that an Episode are nested into each
+other.
 </td>
 <td style="text-align:left;">
-If there are multiple nested levels to how Episodes are represented, the EPISODE_PARENT_ID can be used to record this relationship.
+If there are multiple nested levels to how Episodes are represented, the
+EPISODE_PARENT_ID can be used to record this relationship.
 </td>
 <td style="text-align:left;">
 integer
@@ -10566,7 +12055,9 @@ <h3 class="tabset tabset-pills">EPISODE</h3>
 episode_number
 </td>
 <td style="text-align:left;">
-For sequences of episodes, this is used to indicate the order the episodes occurred. For example, lines of treatment could be indicated here.
+For sequences of episodes, this is used to indicate the order the
+episodes occurred. For example, lines of treatment could be indicated
+here.
 </td>
 <td style="text-align:left;">
 Please see [article] for the details of how to count episodes.
@@ -10593,10 +12084,21 @@ <h3 class="tabset tabset-pills">EPISODE</h3>
 episode_object_concept_id
 </td>
 <td style="text-align:left;">
-A Standard Concept representing the disease phase, outcome, or other abstraction of which the episode consists. For example, if the EPISODE_CONCEPT_ID is <a href="https://athena.ohdsi.org/search-terms/terms/32531">treatment regimen</a> then the EPISODE_OBJECT_CONCEPT_ID should contain the chemotherapy regimen concept, like <a href="https://athena.ohdsi.org/search-terms/terms/35804392">Afatinib monotherapy</a>.
+A Standard Concept representing the disease phase, outcome, or other
+abstraction of which the episode consists. For example, if the
+EPISODE_CONCEPT_ID is <a
+href="https://athena.ohdsi.org/search-terms/terms/32531">treatment
+regimen</a> then the EPISODE_OBJECT_CONCEPT_ID should contain the
+chemotherapy regimen concept, like <a
+href="https://athena.ohdsi.org/search-terms/terms/35804392">Afatinib
+monotherapy</a>.
 </td>
 <td style="text-align:left;">
-Episode entries from the ‘Disease Episode’ concept class should have an episode_object_concept_id that comes from the Condition domain. Episode entries from the ‘Treatment Episode’ concept class should have an episode_object_concept_id that scome from the ‘Procedure’ domain or ‘Regimen’ concept class.
+Episode entries from the ‘Disease Episode’ concept class should have an
+episode_object_concept_id that comes from the Condition domain. Episode
+entries from the ‘Treatment Episode’ concept class should have an
+episode_object_concept_id that scome from the ‘Procedure’ domain or
+‘Regimen’ concept class.
 </td>
 <td style="text-align:left;">
 integer
@@ -10622,10 +12124,18 @@ <h3 class="tabset tabset-pills">EPISODE</h3>
 episode_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Episode record, as in whether the episode was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Episode
+record, as in whether the episode was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the EPISODE_TYPE_CONCEPT_ID that best represents the provenance of the record. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. A more detailed explanation of each Type Concept can be found on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary wiki</a>.
+Choose the EPISODE_TYPE_CONCEPT_ID that best represents the provenance
+of the record. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>. A more detailed explanation of each Type Concept can be
+found on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
+wiki</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -10651,7 +12161,9 @@ <h3 class="tabset tabset-pills">EPISODE</h3>
 episode_source_value
 </td>
 <td style="text-align:left;">
-The source code for the Episdoe as it appears in the source data. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+The source code for the Episdoe as it appears in the source data. This
+code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10677,10 +12189,13 @@ <h3 class="tabset tabset-pills">EPISODE</h3>
 episode_source_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key to a Episode Concept that refers to the code used in the source.
+A foreign key to a Episode Concept that refers to the code used in the
+source.
 </td>
 <td style="text-align:left;">
-Given that the Episodes are user-defined it is unlikely that there will be a Source Concept available. If that is the case then set this field to zero.
+Given that the Episodes are user-defined it is unlikely that there will
+be a Source Concept available. If that is the case then set this field
+to zero.
 </td>
 <td style="text-align:left;">
 integer
@@ -10706,11 +12221,17 @@ <h3 class="tabset tabset-pills">EPISODE</h3>
 <div id="episode_event" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">EPISODE_EVENT</h3>
 <p><strong>Table Description</strong></p>
-<p>The EPISODE_EVENT table connects qualifying clinical events (such as CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT) to the appropriate EPISODE entry. For example, linking the precise location of the metastasis (cancer modifier in MEASUREMENT) to the disease episode.</p>
+<p>The EPISODE_EVENT table connects qualifying clinical events (such as
+CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT)
+to the appropriate EPISODE entry. For example, linking the precise
+location of the metastasis (cancer modifier in MEASUREMENT) to the
+disease episode.</p>
 <p><strong>User Guide</strong></p>
-<p>This connecting table is used instead of the FACT_RELATIONSHIP table for linking low-level events to abstracted Episodes.</p>
+<p>This connecting table is used instead of the FACT_RELATIONSHIP table
+for linking low-level events to abstracted Episodes.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Some episodes may not have links to any underlying clinical events. For such episodes, the EPISODE_EVENT table is not populated.</p>
+<p>Some episodes may not have links to any underlying clinical events.
+For such episodes, the EPISODE_EVENT table is not populated.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10777,7 +12298,9 @@ <h3 class="tabset tabset-pills">EPISODE_EVENT</h3>
 event_id
 </td>
 <td style="text-align:left;">
-This field is the primary key of the linked record in the database. For example, if the Episode Event is a Condition Occurrence, then the CONDITION_OCCURRENCE_ID of the linked record goes in this field.
+This field is the primary key of the linked record in the database. For
+example, if the Episode Event is a Condition Occurrence, then the
+CONDITION_OCCURRENCE_ID of the linked record goes in this field.
 </td>
 <td style="text-align:left;">
 Put the primary key of the linked record here.
@@ -10804,10 +12327,14 @@ <h3 class="tabset tabset-pills">EPISODE_EVENT</h3>
 episode_event_field_concept_id
 </td>
 <td style="text-align:left;">
-This field is the CONCEPT_ID that identifies which table the primary key of the linked record came from.
+This field is the CONCEPT_ID that identifies which table the primary key
+of the linked record came from.
 </td>
 <td style="text-align:left;">
-Put the CONCEPT_ID that identifies which table and field the EVENT_ID came from. <a href="https://athena.ohdsi.org/search-terms/terms?vocabulary=CDM&amp;conceptClass=Field&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+Put the CONCEPT_ID that identifies which table and field the EVENT_ID
+came from. <a
+href="https://athena.ohdsi.org/search-terms/terms?vocabulary=CDM&amp;conceptClass=Field&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -10837,7 +12364,8 @@ <h2><strong>Metadata Tables</strong></h2>
 <div id="metadata" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">METADATA</h3>
 <p><strong>Table Description</strong></p>
-<p>The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.</p>
+<p>The METADATA table contains metadata information about a dataset that
+has been transformed to the OMOP Common Data Model.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11031,7 +12559,9 @@ <h3 class="tabset tabset-pills">METADATA</h3>
 value_as_number
 </td>
 <td style="text-align:left;">
-This is the numerical value of the result of the Metadata, if applicable and available. It is not expected that all Metadata will have numeric results, rather, this field is here to house values should they exist.
+This is the numerical value of the result of the Metadata, if applicable
+and available. It is not expected that all Metadata will have numeric
+results, rather, this field is here to house values should they exist.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11108,7 +12638,9 @@ <h3 class="tabset tabset-pills">METADATA</h3>
 <div id="cdm_source" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CDM_SOURCE</h3>
 <p><strong>Table Description</strong></p>
-<p>The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.</p>
+<p>The CDM_SOURCE table contains detail about the source database and
+the process used to transform the data into the OMOP Common Data
+Model.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11382,7 +12914,9 @@ <h3 class="tabset tabset-pills">CDM_SOURCE</h3>
 The Concept Id representing the version of the CDM.
 </td>
 <td style="text-align:left;">
-You can find all concepts that represent the CDM versions using the query: SELECT * FROM CONCEPT WHERE VOCABULARY_ID = ‘CDM’ AND CONCEPT_CLASS = ‘CDM’
+You can find all concepts that represent the CDM versions using the
+query: SELECT * FROM CONCEPT WHERE VOCABULARY_ID = ‘CDM’ AND
+CONCEPT_CLASS = ‘CDM’
 </td>
 <td style="text-align:left;">
 integer
@@ -11409,7 +12943,8 @@ <h3 class="tabset tabset-pills">CDM_SOURCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-You can find the version of your Vocabulary using the query: SELECT vocabulary_version from vocabulary where vocabulary_id = ‘None’
+You can find the version of your Vocabulary using the query: SELECT
+vocabulary_version from vocabulary where vocabulary_id = ‘None’
 </td>
 <td style="text-align:left;">
 varchar(20)
@@ -11437,9 +12972,26 @@ <h2><strong>Vocabulary Tables</strong></h2>
 <div id="concept" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT</h3>
 <p><strong>Table Description</strong></p>
-<p>The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and within standardized analytics. Each Standard Concept belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.</p>
-<p>Concepts can represent broad categories (like ‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’) or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.).</p>
-<p>Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom Concepts defined to cover various aspects of observational data analysis.</p>
+<p>The Standardized Vocabularies contains records, or Concepts, that
+uniquely identify each fundamental unit of meaning used to express
+clinical information in all domain tables of the CDM. Concepts are
+derived from vocabularies, which represent clinical information across a
+domain (e.g. conditions, drugs, procedures) through the use of codes and
+associated descriptions. Some Concepts are designated Standard Concepts,
+meaning these Concepts can be used as normative expressions of a
+clinical entity within the OMOP Common Data Model and within
+standardized analytics. Each Standard Concept belongs to one domain,
+which defines the location where the Concept would be expected to occur
+within data tables of the CDM.</p>
+<p>Concepts can represent broad categories (like ‘Cardiovascular
+disease’), detailed clinical elements (‘Myocardial infarction of the
+anterolateral wall’) or modifying characteristics and attributes that
+define Concepts at various levels of detail (severity of a disease,
+associated morphology, etc.).</p>
+<p>Records in the Standardized Vocabularies tables are derived from
+national or international vocabularies such as SNOMED-CT, RxNorm, and
+LOINC, or custom Concepts defined to cover various aspects of
+observational data analysis.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11530,7 +13082,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 domain_id
 </td>
 <td style="text-align:left;">
-A foreign key to the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#domain">DOMAIN</a> table the Concept belongs to.
+A foreign key to the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#domain">DOMAIN</a>
+table the Concept belongs to.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11557,7 +13111,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 vocabulary_id
 </td>
 <td style="text-align:left;">
-A foreign key to the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#vocabulary">VOCABULARY</a> table indicating from which source the Concept has been adapted.
+A foreign key to the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#vocabulary">VOCABULARY</a>
+table indicating from which source the Concept has been adapted.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11584,7 +13140,8 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 concept_class_id
 </td>
 <td style="text-align:left;">
-The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc.
+The attribute or concept class of the Concept. Examples are ‘Clinical
+Drug’, ‘Ingredient’, ‘Clinical Finding’ etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11611,7 +13168,10 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 standard_concept
 </td>
 <td style="text-align:left;">
-This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL.
+This flag determines where a Concept is a Standard Concept, i.e. is used
+in the data, a Classification Concept, or a non-standard Source Concept.
+The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification
+Concept), otherwise the content is NULL.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11637,7 +13197,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 concept_code
 </td>
 <td style="text-align:left;">
-The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies.
+The concept code represents the identifier of the Concept in the source
+vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that
+concept codes are not unique across vocabularies.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11663,7 +13225,8 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 valid_start_date
 </td>
 <td style="text-align:left;">
-The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning, the Concept has no (known) date of inception.
+The date when the Concept was first recorded. The default value is
+1-Jan-1970, meaning, the Concept has no (known) date of inception.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11689,7 +13252,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 valid_end_date
 </td>
 <td style="text-align:left;">
-The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning, the Concept is valid until it becomes deprecated.
+The date when the Concept became invalid because it was deleted or
+superseded (updated) by a new concept. The default value is 31-Dec-2099,
+meaning, the Concept is valid until it becomes deprecated.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11715,7 +13280,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-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.
+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.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11742,7 +13309,11 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 <div id="vocabulary" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">VOCABULARY</h3>
 <p><strong>Table Description</strong></p>
-<p>The VOCABULARY table includes a list of the Vocabularies collected from various sources or created de novo by the OMOP community. This reference table is populated with a single record for each Vocabulary source and includes a descriptive name and other associated attributes for the Vocabulary.</p>
+<p>The VOCABULARY table includes a list of the Vocabularies collected
+from various sources or created de novo by the OMOP community. This
+reference table is populated with a single record for each Vocabulary
+source and includes a descriptive name and other associated attributes
+for the Vocabulary.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11807,7 +13378,9 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 vocabulary_name
 </td>
 <td style="text-align:left;">
-The name describing the vocabulary, for example, International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS) etc.
+The name describing the vocabulary, for example, International
+Classification of Diseases, Ninth Revision, Clinical Modification,
+Volume 1 and 2 (NCHS) etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11833,7 +13406,8 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 vocabulary_reference
 </td>
 <td style="text-align:left;">
-External reference to documentation or available download of the about the vocabulary.
+External reference to documentation or available download of the about
+the vocabulary.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11885,7 +13459,8 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 vocabulary_concept_id
 </td>
 <td style="text-align:left;">
-A Concept that represents the Vocabulary the VOCABULARY record belongs to.
+A Concept that represents the Vocabulary the VOCABULARY record belongs
+to.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11913,7 +13488,14 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 <div id="domain" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DOMAIN</h3>
 <p><strong>Table Description</strong></p>
-<p>The DOMAIN table includes a list of OMOP-defined Domains the Concepts of the Standardized Vocabularies can belong to. A Domain defines the set of allowable Concepts for the standardized fields in the CDM tables. For example, the “Condition” Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.</p>
+<p>The DOMAIN table includes a list of OMOP-defined Domains the Concepts
+of the Standardized Vocabularies can belong to. A Domain defines the set
+of allowable Concepts for the standardized fields in the CDM tables. For
+example, the “Condition” Domain contains Concepts that describe a
+condition of a patient, and these Concepts can only be stored in the
+condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA
+tables. This reference table is populated with a single record for each
+Domain and includes a descriptive name for the Domain.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11978,7 +13560,8 @@ <h3 class="tabset tabset-pills">DOMAIN</h3>
 domain_name
 </td>
 <td style="text-align:left;">
-The name describing the Domain, e.g. Condition, Procedure, Measurement etc.
+The name describing the Domain, e.g. Condition, Procedure, Measurement
+etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12032,7 +13615,10 @@ <h3 class="tabset tabset-pills">DOMAIN</h3>
 <div id="concept_class" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_CLASS</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_CLASS table is a reference table, which includes a list of the classifications used to differentiate Concepts within a given Vocabulary. This reference table is populated with a single record for each Concept Class.</p>
+<p>The CONCEPT_CLASS table is a reference table, which includes a list
+of the classifications used to differentiate Concepts within a given
+Vocabulary. This reference table is populated with a single record for
+each Concept Class.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12097,7 +13683,8 @@ <h3 class="tabset tabset-pills">CONCEPT_CLASS</h3>
 concept_class_name
 </td>
 <td style="text-align:left;">
-The name describing the Concept Class, e.g. Clinical Finding, Ingredient, etc.
+The name describing the Concept Class, e.g. Clinical Finding,
+Ingredient, etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12148,10 +13735,14 @@ <h3 class="tabset tabset-pills">CONCEPT_CLASS</h3>
 </tbody>
 </table>
 </div>
-<div id="concept_relationship" class="section level3 tabset tabset-pills">
+<div id="concept_relationship"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the RELATIONSHIP table.</p>
+<p>The CONCEPT_RELATIONSHIP table contains records that define direct
+relationships between any two Concepts and the nature or type of the
+relationship. Each type of a relationship is defined in the RELATIONSHIP
+table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12242,7 +13833,10 @@ <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 relationship_id
 </td>
 <td style="text-align:left;">
-The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the <a href="https://ohdsi.github.io/CommonDataModel/dataModelConventions.html#concept_relationships">Vocabulary Conventions</a>. for more information.
+The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the
+<a
+href="https://ohdsi.github.io/CommonDataModel/dataModelConventions.html#concept_relationships">Vocabulary
+Conventions</a>. for more information.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12321,7 +13915,8 @@ <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-Reason the relationship was invalidated. Possible values are ‘D’ (deleted), ‘U’ (updated) or NULL.
+Reason the relationship was invalidated. Possible values are ‘D’
+(deleted), ‘U’ (updated) or NULL.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12348,7 +13943,9 @@ <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 <div id="relationship" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 <p><strong>Table Description</strong></p>
-<p>The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.</p>
+<p>The RELATIONSHIP table provides a reference list of all types of
+relationships that can be used to associate any two concepts in the
+CONCEPT_RELATIONSHP table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12438,7 +14035,8 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 is_hierarchical
 </td>
 <td style="text-align:left;">
-Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not.
+Defines whether a relationship defines concepts into classes or
+hierarchies. Values are 1 for hierarchical relationship or 0 if not.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12464,7 +14062,9 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 defines_ancestry
 </td>
 <td style="text-align:left;">
-Defines whether a hierarchical relationship contributes to the concept_ancestor table. These are subsets of the hierarchical relationships. Valid values are 1 or 0.
+Defines whether a hierarchical relationship contributes to the
+concept_ancestor table. These are subsets of the hierarchical
+relationships. Valid values are 1 or 0.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12490,7 +14090,8 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 reverse_relationship_id
 </td>
 <td style="text-align:left;">
-The identifier for the relationship used to define the reverse relationship between two concepts.
+The identifier for the relationship used to define the reverse
+relationship between two concepts.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12516,7 +14117,9 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 relationship_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key that refers to an identifier in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept">CONCEPT</a> table for the unique relationship concept.
+A foreign key that refers to an identifier in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept">CONCEPT</a>
+table for the unique relationship concept.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12544,7 +14147,8 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 <div id="concept_synonym" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_SYNONYM</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.</p>
+<p>The CONCEPT_SYNONYM table is used to store alternate names and
+descriptions for Concepts.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12661,8 +14265,19 @@ <h3 class="tabset tabset-pills">CONCEPT_SYNONYM</h3>
 <div id="concept_ancestor" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.</p>
-<p>This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.</p>
+<p>The CONCEPT_ANCESTOR table is designed to simplify observational
+analysis by providing the complete hierarchical relationships between
+Concepts. Only direct parent-child relationships between Concepts are
+stored in the CONCEPT_RELATIONSHIP table. To determine higher level
+ancestry connections, all individual direct relationships would have to
+be navigated at analysis time. The CONCEPT_ANCESTOR table includes
+records for all parent-child relationships, as well as
+grandparent-grandchild relationships and those of any other level of
+lineage. Using the CONCEPT_ANCESTOR table allows for querying for all
+descendants of a hierarchical concept. For example, drug ingredients and
+drug products are all descendants of a drug class ancestor.</p>
+<p>This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP
+and RELATIONSHIP tables.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12701,7 +14316,8 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 ancestor_concept_id
 </td>
 <td style="text-align:left;">
-The Concept Id for the higher-level concept that forms the ancestor in the relationship.
+The Concept Id for the higher-level concept that forms the ancestor in
+the relationship.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12728,7 +14344,8 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 descendant_concept_id
 </td>
 <td style="text-align:left;">
-The Concept Id for the lower-level concept that forms the descendant in the relationship.
+The Concept Id for the lower-level concept that forms the descendant in
+the relationship.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12755,7 +14372,9 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 min_levels_of_separation
 </td>
 <td style="text-align:left;">
-The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.
+The minimum separation in number of levels of hierarchy between ancestor
+and descendant concepts. This is an attribute that is used to simplify
+hierarchic analysis.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12781,7 +14400,9 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 max_levels_of_separation
 </td>
 <td style="text-align:left;">
-The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.
+The maximum separation in number of levels of hierarchy between ancestor
+and descendant concepts. This is an attribute that is used to simplify
+hierarchic analysis.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12805,10 +14426,18 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 </tbody>
 </table>
 </div>
-<div id="source_to_concept_map" class="section level3 tabset tabset-pills">
+<div id="source_to_concept_map"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 <p><strong>Table Description</strong></p>
-<p>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.</p>
+<p>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.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12873,10 +14502,12 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 source_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key to the Source Concept that is being translated into a Standard Concept.
+A foreign key to the Source Concept that is being translated into a
+Standard Concept.
 </td>
 <td style="text-align:left;">
-This is either 0 or should be a number above 2 billion, which are the Concepts reserved for site-specific codes and mappings.
+This is either 0 or should be a number above 2 billion, which are the
+Concepts reserved for site-specific codes and mappings.
 </td>
 <td style="text-align:left;">
 integer
@@ -12901,7 +14532,8 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 source_vocabulary_id
 </td>
 <td style="text-align:left;">
-A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept.
+A foreign key to the VOCABULARY table defining the vocabulary of the
+source code that is being translated to a Standard Concept.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12927,7 +14559,9 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 source_code_description
 </td>
 <td style="text-align:left;">
-An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept.
+An optional description for the source code. This is included as a
+convenience to compare the description of the source code to the name of
+the concept.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13033,7 +14667,9 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 valid_end_date
 </td>
 <td style="text-align:left;">
-The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. Default value is 31-Dec-2099.
+The date when the mapping instance became invalid because it was deleted
+or superseded (updated) by a new relationship. Default value is
+31-Dec-2099.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13059,7 +14695,9 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value.
+Reason the mapping instance was invalidated. Possible values are D
+(deleted), U (replaced with an update) or NULL when valid_end_date has
+the default value.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13086,7 +14724,10 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 <div id="drug_strength" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 <p><strong>Table Description</strong></p>
-<p>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.</p>
+<p>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.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -13152,10 +14793,12 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 ingredient_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the active ingredient contained within the drug product.
+The Concept representing the active ingredient contained within the drug
+product.
 </td>
 <td style="text-align:left;">
-Combination Drugs will have more than one record in this table, one for each active Ingredient.
+Combination Drugs will have more than one record in this table, one for
+each active Ingredient.
 </td>
 <td style="text-align:left;">
 integer
@@ -13180,7 +14823,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 amount_value
 </td>
 <td style="text-align:left;">
-The numeric value or the amount of active ingredient contained within the drug product.
+The numeric value or the amount of active ingredient contained within
+the drug product.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13206,7 +14850,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 amount_unit_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the Unit of measure for the amount of active ingredient contained within the drug product.
+The Concept representing the Unit of measure for the amount of active
+ingredient contained within the drug product.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13233,7 +14878,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 numerator_value
 </td>
 <td style="text-align:left;">
-The concentration of the active ingredient contained within the drug product.
+The concentration of the active ingredient contained within the drug
+product.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13259,7 +14905,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 numerator_unit_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the Unit of measure for the concentration of active ingredient.
+The Concept representing the Unit of measure for the concentration of
+active ingredient.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13286,7 +14933,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 denominator_value
 </td>
 <td style="text-align:left;">
-The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.).
+The amount of total liquid (or other divisible product, such as
+ointment, gel, spray, etc.).
 </td>
 <td style="text-align:left;">
 </td>
@@ -13312,7 +14960,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 denominator_unit_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the denominator unit for the concentration of active ingredient.
+The Concept representing the denominator unit for the concentration of
+active ingredient.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13339,7 +14988,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 box_size
 </td>
 <td style="text-align:left;">
-The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient.
+The number of units of Clinical Branded Drug or Quantified Clinical or
+Branded Drug contained in a box as dispensed to the patient.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13365,7 +15015,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 valid_start_date
 </td>
 <td style="text-align:left;">
-The date when the Concept was first recorded. The default value is 1-Jan-1970.
+The date when the Concept was first recorded. The default value is
+1-Jan-1970.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13417,7 +15068,9 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-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.
+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.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13444,9 +15097,28 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 <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>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>
+<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>
@@ -13586,7 +15258,15 @@ <h3 class="tabset tabset-pills">COHORT</h3>
 <div id="cohort_definition" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 <p><strong>Table Description</strong></p>
-<p>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.</p>
+<p>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.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -13625,7 +15305,8 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 cohort_definition_id
 </td>
 <td style="text-align:left;">
-This is the identifier given to the cohort, usually by the ATLAS application
+This is the identifier given to the cohort, usually by the ATLAS
+application
 </td>
 <td style="text-align:left;">
 </td>
@@ -13703,7 +15384,8 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 definition_type_concept_id
 </td>
 <td style="text-align:left;">
-Type defining what kind of Cohort Definition the record represents and how the syntax may be executed.
+Type defining what kind of Cohort Definition the record represents and
+how the syntax may be executed.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13756,7 +15438,8 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 subject_concept_id
 </td>
 <td style="text-align:left;">
-This field contains a Concept that represents the domain of the subjects that are members of the cohort (e.g., Person, Provider, Visit).
+This field contains a Concept that represents the domain of the subjects
+that are members of the cohort (e.g., Person, Provider, Visit).
 </td>
 <td style="text-align:left;">
 </td>
diff --git a/docs/cdm54Changes.html b/docs/cdm54Changes.html
index 33bcb807..d58585f8 100644
--- a/docs/cdm54Changes.html
+++ b/docs/cdm54Changes.html
@@ -13,7 +13,7 @@
 
 <title>Changes by Table</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -493,12 +497,17 @@ <h1 class="title toc-ignore"><strong>Changes by Table</strong></h1>
 
 
 <p><em>from CDM v5.3 -&gt; CDM v5.4</em></p>
-<p>For a full description of each table and field listed here, please see the <a href="http://ohdsi.github.io/CommonDataModel/cdm54.html">CDM specification</a>.</p>
+<p>For a full description of each table and field listed here, please
+see the <a href="http://ohdsi.github.io/CommonDataModel/cdm54.html">CDM
+specification</a>.</p>
 <p>Notation:</p>
 <ul>
-<li>a <strong>+</strong> indicates an addition to the model, either a table or field</li>
-<li>a <strong>-&gt;</strong> indicates an alteration either in naming or specification</li>
-<li>a <strong>-</strong> indicates a subtraction from the model, either a table or field</li>
+<li>a <strong>+</strong> indicates an addition to the model, either a
+table or field</li>
+<li>a <strong>-&gt;</strong> indicates an alteration either in naming or
+specification</li>
+<li>a <strong>-</strong> indicates a subtraction from the model, either
+a table or field</li>
 </ul>
 <div id="person" class="section level2">
 <h2>PERSON</h2>
@@ -515,20 +524,29 @@ <h2>OBSERVATION_PERIOD</h2>
 <div id="visit_occurrence" class="section level2">
 <h2>VISIT_OCCURRENCE</h2>
 <ul>
-<li>Admitting_source_concept_id -&gt; <strong>Admitted_from_concept_id</strong></li>
-<li>Admitting_source_value -&gt; <strong>Admitted_from_source_value</strong></li>
-<li>Discharge_to_concept_id -&gt; <strong>Discharged_to_concept_id</strong></li>
-<li>Discharge_to_source_value -&gt; <strong>Discharged_to_source_value</strong></li>
+<li>Admitting_source_concept_id -&gt;
+<strong>Admitted_from_concept_id</strong></li>
+<li>Admitting_source_value -&gt;
+<strong>Admitted_from_source_value</strong></li>
+<li>Discharge_to_concept_id -&gt;
+<strong>Discharged_to_concept_id</strong></li>
+<li>Discharge_to_source_value -&gt;
+<strong>Discharged_to_source_value</strong></li>
 </ul>
 </div>
 <div id="visit_detail" class="section level2">
 <h2>VISIT_DETAIL</h2>
 <ul>
-<li>Admitting_source_concept_id -&gt; <strong>Admitted_from_concept_id</strong></li>
-<li>Admitting_source_value -&gt; <strong>Admitted_from_source_value</strong></li>
-<li>Discharge_to_concept_id -&gt; <strong>Discharged_to_concept_id</strong></li>
-<li>Discharge_to_source_value -&gt; <strong>Discharged_to_source_value</strong></li>
-<li>Visit_detail_parent_id -&gt; <strong>Parent_visit_detail_id</strong></li>
+<li>Admitting_source_concept_id -&gt;
+<strong>Admitted_from_concept_id</strong></li>
+<li>Admitting_source_value -&gt;
+<strong>Admitted_from_source_value</strong></li>
+<li>Discharge_to_concept_id -&gt;
+<strong>Discharged_to_concept_id</strong></li>
+<li>Discharge_to_source_value -&gt;
+<strong>Discharged_to_source_value</strong></li>
+<li>Visit_detail_parent_id -&gt;
+<strong>Parent_visit_detail_id</strong></li>
 </ul>
 </div>
 <div id="condition_occurrence" class="section level2">
diff --git a/docs/cdm60.html b/docs/cdm60.html
index 22469223..dc898ee2 100644
--- a/docs/cdm60.html
+++ b/docs/cdm60.html
@@ -13,7 +13,7 @@
 
 <title>OMOP CDM v6.0</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -494,20 +498,58 @@ <h1 class="title toc-ignore"><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.0">CDM v5.4</a> until such time that the v6 series of the CDM is ready for mainstream use.</strong></p>
-<p>Below is the specification document for the OMOP Common Data Model, v6.0. Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the <a href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a> page.</p>
-<p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm documentation link to forum on doc page</p>
+<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.0">CDM
+v5.4</a> until such time that the v6 series of the CDM is ready for
+mainstream use.</strong></p>
+<p>Below is the specification document for the OMOP Common Data Model,
+v6.0. Each table is represented with a high-level description and ETL
+conventions that should be followed. This is continued with a discussion
+of each field in each table, any conventions related to the field, and
+constraints that should be followed (like primary key, foreign key,
+etc). Should you have questions please feel free to visit the <a
+href="https://forums.ohdsi.org/">forums</a> or the <a
+href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a>
+page.</p>
+<p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm
+documentation link to forum on doc page</p>
 </div>
 <div id="changes-in-v6.0" class="section level2">
 <h2><strong>Changes in v6.0</strong></h2>
 <ul>
-<li>Latitude and Longitude added to <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location">LOCATION</a></li>
-<li>Contract owner field added to <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#payer_plan_period">PAYER_PLAN_PERIOD</a></li>
+<li>Latitude and Longitude added to <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location">LOCATION</a></li>
+<li>Contract owner field added to <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#payer_plan_period">PAYER_PLAN_PERIOD</a></li>
 <li>All primary keys were changed to bigint</li>
-<li>The name of ADMISSION_SOURCE_CONCEPT_ID was changed to ADMITTED_FROM_CONCEPT_ID in <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#visit_occurrence">VISIT_OCCURRENCE</a> and <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#visit_detail">VISIT_DETAIL</a></li>
-<li>All Concept_Ids are now mandatory except for UNIT_CONCEPT_ID, VALUE_AS_CONCEPT_ID, and OPERATOR_CONCEPT_ID. If there is no value available then a Concept_Id should be set to 0 instead of NULL.</li>
-<li><a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#death">DEATH</a> table removed and DEATH_DATETIME field added to the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#person">PERSON</a> table. Cause of death is stored in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#condition_occurrence">CONDITION_OCCURRENCE</a></li>
-<li>DATETIME fields were made mandatory and date fields were made optional.</li>
+<li>The name of ADMISSION_SOURCE_CONCEPT_ID was changed to
+ADMITTED_FROM_CONCEPT_ID in <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#visit_occurrence">VISIT_OCCURRENCE</a>
+and <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#visit_detail">VISIT_DETAIL</a></li>
+<li>All Concept_Ids are now mandatory except for UNIT_CONCEPT_ID,
+VALUE_AS_CONCEPT_ID, and OPERATOR_CONCEPT_ID. If there is no value
+available then a Concept_Id should be set to 0 instead of NULL.</li>
+<li><a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#death">DEATH</a>
+table removed and DEATH_DATETIME field added to the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#person">PERSON</a>
+table. Cause of death is stored in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#condition_occurrence">CONDITION_OCCURRENCE</a></li>
+<li>DATETIME fields were made mandatory and date fields were made
+optional.</li>
 </ul>
 </div>
 <div id="clinical-data-tables" class="section level2">
@@ -515,11 +557,32 @@ <h2><strong>Clinical Data Tables</strong></h2>
 <div id="person" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PERSON</h3>
 <p><strong>Table Description</strong></p>
-<p>This table serves as the central identity management for all Persons in the database. It contains records that uniquely identify each person or patient, and some demographic information.</p>
+<p>This table serves as the central identity management for all Persons
+in the database. It contains records that uniquely identify each person
+or patient, and some demographic information.</p>
 <p><strong>User Guide</strong></p>
 <p>All records in this table are independent Persons.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>All Persons in a database needs one record in this table, unless they fail data quality requirements specified in the ETL. Persons with no Events should have a record nonetheless. If more than one data source contributes Events to the database, Persons must be reconciled, if possible, across the sources to create one single record per Person. The BIRTH_DATETIME must be equivalent to the content of BIRTH_DAY, BIRTH_MONTH and BIRTH_YEAR. There is a helpful rule listed in table below for how to derive BIRTH_DATETIME if it is not available in the source. <strong>New to CDM v6.0</strong> The person’s death date is now stored in this table instead of the separate DEATH table. In the case that multiple dates of death are given in the source data the ETL should make a choice as to which death date to put in the PERSON table. Any additional dates can be stored in the OBSERVATION table using the concept <a href="https://athena.ohdsi.org/search-terms/terms/4265167">4265167</a> which stands for ‘Date of death’ . Similarly, the cause of death is stored in the CONDITION_OCCURRENCE table using the CONDITION_STATUS_CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/32891">32891</a> for ‘Cause of death’.</p>
+<p>All Persons in a database needs one record in this table, unless they
+fail data quality requirements specified in the ETL. Persons with no
+Events should have a record nonetheless. If more than one data source
+contributes Events to the database, Persons must be reconciled, if
+possible, across the sources to create one single record per Person. The
+BIRTH_DATETIME must be equivalent to the content of BIRTH_DAY,
+BIRTH_MONTH and BIRTH_YEAR. There is a helpful rule listed in table
+below for how to derive BIRTH_DATETIME if it is not available in the
+source. <strong>New to CDM v6.0</strong> The person’s death date is now
+stored in this table instead of the separate DEATH table. In the case
+that multiple dates of death are given in the source data the ETL should
+make a choice as to which death date to put in the PERSON table. Any
+additional dates can be stored in the OBSERVATION table using the
+concept <a
+href="https://athena.ohdsi.org/search-terms/terms/4265167">4265167</a>
+which stands for ‘Date of death’ . Similarly, the cause of death is
+stored in the CONDITION_OCCURRENCE table using the
+CONDITION_STATUS_CONCEPT_ID <a
+href="https://athena.ohdsi.org/search-terms/terms/32891">32891</a> for
+‘Cause of death’.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -558,10 +621,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 person_id
 </td>
 <td style="text-align:left;">
-It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently.
+It is assumed that every person with a different unique identifier is in
+fact a different person and should be treated independently.
 </td>
 <td style="text-align:left;">
-Any person linkage that needs to occur to uniquely identify Persons ought to be done prior to writing this table. This identifier can be the original id from the source data provided if it is an integer, otherwise it can be an autogenerated number.
+Any person linkage that needs to occur to uniquely identify Persons
+ought to be done prior to writing this table. This identifier can be the
+original id from the source data provided if it is an integer, otherwise
+it can be an autogenerated number.
 </td>
 <td style="text-align:left;">
 bigint
@@ -585,10 +652,17 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 gender_concept_id
 </td>
 <td style="text-align:left;">
-This field is meant to capture the biological sex at birth of the Person. This field should not be used to study gender identity issues.
+This field is meant to capture the biological sex at birth of the
+Person. This field should not be used to study gender identity issues.
 </td>
 <td style="text-align:left;">
-Use the gender or sex value present in the data under the assumption that it is the biological sex at birth. If the source data captures gender identity it should be stored in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#observation">OBSERVATION</a> table. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted gender concepts</a>
+Use the gender or sex value present in the data under the assumption
+that it is the biological sex at birth. If the source data captures
+gender identity it should be stored in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#observation">OBSERVATION</a>
+table. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+gender concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -617,7 +691,10 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Compute age using year_of_birth.
 </td>
 <td style="text-align:left;">
-For data sources with date of birth, the year should be extracted. For data sources where the year of birth is not available, the approximate year of birth could be derived based on age group categorization, if available.
+For data sources with date of birth, the year should be extracted. For
+data sources where the year of birth is not available, the approximate
+year of birth could be derived based on age group categorization, if
+available.
 </td>
 <td style="text-align:left;">
 integer
@@ -643,7 +720,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-For data sources that provide the precise date of birth, the month should be extracted and stored in this field.
+For data sources that provide the precise date of birth, the month
+should be extracted and stored in this field.
 </td>
 <td style="text-align:left;">
 integer
@@ -669,7 +747,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-For data sources that provide the precise date of birth, the day should be extracted and stored in this field.
+For data sources that provide the precise date of birth, the day should
+be extracted and stored in this field.
 </td>
 <td style="text-align:left;">
 integer
@@ -695,7 +774,15 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This field is not required but highly encouraged. For data sources that provide the precise datetime of birth, that value should be stored in this field. If birth_datetime is not provided in the source, use the following logic to infer the date: If day_of_birth is null and month_of_birth is not null then use the first of the month in that year. If month_of_birth is null or if day_of_birth AND month_of_birth are both null and the person has records during their year of birth then use the date of the earliest record, otherwise use the 15th of June of that year. If time of birth is not given use midnight (00:00:0000).
+This field is not required but highly encouraged. For data sources that
+provide the precise datetime of birth, that value should be stored in
+this field. If birth_datetime is not provided in the source, use the
+following logic to infer the date: If day_of_birth is null and
+month_of_birth is not null then use the first of the month in that year.
+If month_of_birth is null or if day_of_birth AND month_of_birth are both
+null and the person has records during their year of birth then use the
+date of the earliest record, otherwise use the 15th of June of that
+year. If time of birth is not given use midnight (00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -719,10 +806,24 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 death_datetime
 </td>
 <td style="text-align:left;">
-This field is the death date to be used in analysis, as determined by the ETL logic. Any additional information about a Person’s death is stored in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#observation">OBSERVATION</a> table with the concept_id <a href="https://athena.ohdsi.org/search-terms/terms/4306655">4306655</a> or in the CONDITION_OCCURRENCE .
+This field is the death date to be used in analysis, as determined by
+the ETL logic. Any additional information about a Person’s death is
+stored in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#observation">OBSERVATION</a>
+table with the concept_id <a
+href="https://athena.ohdsi.org/search-terms/terms/4306655">4306655</a>
+or in the CONDITION_OCCURRENCE .
 </td>
 <td style="text-align:left;">
-If there are multiple dates of death given for a Person, choose the one that is deemed most reliable. This may be a discharge from the hospital where the Person is listed as deceased or it could be latest death date provided. If a patient has clinical activity more than 60 days after the death date given in the source, it is a viable option to drop the death record as it may have been falsely reported. Similarly, if the death record is from a reputable source (e.g. government provided information) it is also a viable option to remove event records that occur in the data &gt; 60 days after death.
+If there are multiple dates of death given for a Person, choose the one
+that is deemed most reliable. This may be a discharge from the hospital
+where the Person is listed as deceased or it could be latest death date
+provided. If a patient has clinical activity more than 60 days after the
+death date given in the source, it is a viable option to drop the death
+record as it may have been falsely reported. Similarly, if the death
+record is from a reputable source (e.g. government provided information)
+it is also a viable option to remove event records that occur in the
+data &gt; 60 days after death.
 </td>
 <td style="text-align:left;">
 datetime
@@ -747,7 +848,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 This field captures race or ethnic background of the person.
 </td>
 <td style="text-align:left;">
-Only use this field if you have information about race or ethnic background. The Vocabulary contains Concepts about the main races and ethnic backgrounds in a hierarchical system. Due to the imprecise nature of human races and ethnic backgrounds, this is not a perfect system. Mixed races are not supported. If a clear race or ethnic background cannot be established, use Concept_Id 0. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Race&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Race Concepts</a>.
+Only use this field if you have information about race or ethnic
+background. The Vocabulary contains Concepts about the main races and
+ethnic backgrounds in a hierarchical system. Due to the imprecise nature
+of human races and ethnic backgrounds, this is not a perfect system.
+Mixed races are not supported. If a clear race or ethnic background
+cannot be established, use Concept_Id 0. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Race&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Race Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -773,10 +881,17 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 ethnicity_concept_id
 </td>
 <td style="text-align:left;">
-This field captures Ethnicity as defined by the Office of Management and Budget (OMB) of the US Government: it distinguishes only between “Hispanic” and “Not Hispanic”. Races and ethnic backgrounds are not stored here.
+This field captures Ethnicity as defined by the Office of Management and
+Budget (OMB) of the US Government: it distinguishes only between
+“Hispanic” and “Not Hispanic”. Races and ethnic backgrounds are not
+stored here.
 </td>
 <td style="text-align:left;">
-Only use this field if you have US-based data and a source of this information. Do not attempt to infer Ethnicity from the race or ethnic background of the Person. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Ethnicity&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted ethnicity concepts</a>
+Only use this field if you have US-based data and a source of this
+information. Do not attempt to infer Ethnicity from the race or ethnic
+background of the Person. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Ethnicity&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+ethnicity concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -802,10 +917,22 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 location_id
 </td>
 <td style="text-align:left;">
-The location refers to the physical address of the person. This field should capture the last known location of the person. Any prior locations are captured in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a> table.
+The location refers to the physical address of the person. This field
+should capture the last known location of the person. Any prior
+locations are captured in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a>
+table.
 </td>
 <td style="text-align:left;">
-Put the location_id from the LOCATION table here that represents the most granular location information for the person. This could represent anything from postal code or parts thereof, state, or county for example. Since many databases contain deidentified data, it is common that the precision of the location is reduced to prevent re-identification. This field should capture the last known location. Any prior locations are captured in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a> table.
+Put the location_id from the LOCATION table here that represents the
+most granular location information for the person. This could represent
+anything from postal code or parts thereof, state, or county for
+example. Since many databases contain deidentified data, it is common
+that the precision of the location is reduced to prevent
+re-identification. This field should capture the last known location.
+Any prior locations are captured in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a>
+table.
 </td>
 <td style="text-align:left;">
 bigint
@@ -830,10 +957,13 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The Provider refers to the last known primary care provider (General Practitioner).
+The Provider refers to the last known primary care provider (General
+Practitioner).
 </td>
 <td style="text-align:left;">
-Put the provider_id from the PROVIDER table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here.
+Put the provider_id from the PROVIDER table of the last known general
+practitioner of the person. If there are multiple providers, it is up to
+the ETL to decide which to put here.
 </td>
 <td style="text-align:left;">
 bigint
@@ -858,7 +988,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-The Care Site refers to where the Provider typically provides the primary care.
+The Care Site refers to where the Provider typically provides the
+primary care.
 </td>
 <td style="text-align:left;">
 </td>
@@ -885,10 +1016,14 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 person_source_value
 </td>
 <td style="text-align:left;">
-Use this field to link back to persons in the source data. This is typically used for error checking of ETL logic.
+Use this field to link back to persons in the source data. This is
+typically used for error checking of ETL logic.
 </td>
 <td style="text-align:left;">
-Some use cases require the ability to link back to persons in the source data. This field allows for the storing of the person value as it appears in the source. This field is not required but strongly recommended.
+Some use cases require the ability to link back to persons in the source
+data. This field allows for the storing of the person value as it
+appears in the source. This field is not required but strongly
+recommended.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -912,7 +1047,9 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 gender_source_value
 </td>
 <td style="text-align:left;">
-This field is used to store the biological sex of the person from the source data. It is not intended for use in standard analytics but for reference only.
+This field is used to store the biological sex of the person from the
+source data. It is not intended for use in standard analytics but for
+reference only.
 </td>
 <td style="text-align:left;">
 Put the biological sex of the person as it appears in the source data.
@@ -942,7 +1079,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes biological sex in a non-standard vocabulary, store the concept_id here, otherwise set to 0.
+If the source data codes biological sex in a non-standard vocabulary,
+store the concept_id here, otherwise set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -967,7 +1105,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 race_source_value
 </td>
 <td style="text-align:left;">
-This field is used to store the race of the person from the source data. It is not intended for use in standard analytics but for reference only.
+This field is used to store the race of the person from the source data.
+It is not intended for use in standard analytics but for reference only.
 </td>
 <td style="text-align:left;">
 Put the race of the person as it appears in the source data.
@@ -997,7 +1136,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes race in an OMOP supported vocabulary store the concept_id here, otherwise set to 0.
+If the source data codes race in an OMOP supported vocabulary store the
+concept_id here, otherwise set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -1022,10 +1162,13 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 ethnicity_source_value
 </td>
 <td style="text-align:left;">
-This field is used to store the ethnicity of the person from the source data. It is not intended for use in standard analytics but for reference only.
+This field is used to store the ethnicity of the person from the source
+data. It is not intended for use in standard analytics but for reference
+only.
 </td>
 <td style="text-align:left;">
-If the person has an ethnicity other than the OMB standard of “Hispanic” or “Not Hispanic” store that value from the source data here.
+If the person has an ethnicity other than the OMB standard of “Hispanic”
+or “Not Hispanic” store that value from the source data here.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1052,7 +1195,8 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes ethnicity in an OMOP supported vocabulary, store the concept_id here, otherwise set to 0.
+If the source data codes ethnicity in an OMOP supported vocabulary,
+store the concept_id here, otherwise set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -1078,11 +1222,44 @@ <h3 class="tabset tabset-pills">PERSON</h3>
 <div id="observation_period" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains records which define spans of time during which two conditions are expected to hold: (i) Clinical Events that happened to the Person are recorded in the Event tables, and (ii) absense of records indicate such Events did not occur during this span of time.</p>
+<p>This table contains records which define spans of time during which
+two conditions are expected to hold: (i) Clinical Events that happened
+to the Person are recorded in the Event tables, and (ii) absense of
+records indicate such Events did not occur during this span of time.</p>
 <p><strong>User Guide</strong></p>
-<p>For each Person, one or more OBSERVATION_PERIOD records may be present, but they will not overlap or be back to back to each other. Events may exist outside all of the time spans of the OBSERVATION_PERIOD records for a patient, however, absence of an Event outside these time spans cannot be construed as evidence of absence of an Event. Incidence or prevalence rates should only be calculated for the time of active OBSERVATION_PERIOD records. When constructing cohorts, outside Events can be used for inclusion criteria definition, but without any guarantee for the performance of these criteria. Also, OBSERVATION_PERIOD records can be as short as a single day, greatly disturbing the denominator of any rate calculation as part of cohort characterizations. To avoid that, apply minimal observation time as a requirement for any cohort definition.</p>
+<p>For each Person, one or more OBSERVATION_PERIOD records may be
+present, but they will not overlap or be back to back to each other.
+Events may exist outside all of the time spans of the OBSERVATION_PERIOD
+records for a patient, however, absence of an Event outside these time
+spans cannot be construed as evidence of absence of an Event. Incidence
+or prevalence rates should only be calculated for the time of active
+OBSERVATION_PERIOD records. When constructing cohorts, outside Events
+can be used for inclusion criteria definition, but without any guarantee
+for the performance of these criteria. Also, OBSERVATION_PERIOD records
+can be as short as a single day, greatly disturbing the denominator of
+any rate calculation as part of cohort characterizations. To avoid that,
+apply minimal observation time as a requirement for any cohort
+definition.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrollment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
+<p>Each Person needs to have at least one OBSERVATION_PERIOD record,
+which should represent time intervals with a high capture rate of
+Clinical Events. Some source data have very similar concepts, such as
+enrollment periods in insurance claims data. In other source data such
+as most EHR systems these time spans need to be inferred under a set of
+assumptions. It is the discretion of the ETL developer to define these
+assumptions. In many ETL solutions the start date of the first
+occurrence or the first high quality occurrence of a Clinical Event
+(Condition, Drug, Procedure, Device, Measurement, Visit) is defined as
+the start of the OBSERVATION_PERIOD record, and the end date of the last
+occurrence of last high quality occurrence of a Clinical Event, or the
+end of the database period becomes the end of the OBSERVATOIN_PERIOD for
+each Person. If a Person only has a single Clinical Event the
+OBSERVATION_PERIOD record can be as short as one day. Depending on these
+definitions it is possible that Clinical Events fall outside the time
+spans defined by OBSERVATION_PERIOD records. Family history or history
+of Clinical Events generally are not used to generate OBSERVATION_PERIOD
+records around the time they are referring to. Any two overlapping or
+adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -1121,10 +1298,12 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 observation_period_id
 </td>
 <td style="text-align:left;">
-A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id.
+A Person can have multiple discrete Observation Periods which are
+identified by the Observation_Period_Id.
 </td>
 <td style="text-align:left;">
-Assign a unique observation_period_id to each discrete Observation Period for a Person.
+Assign a unique observation_period_id to each discrete Observation
+Period for a Person.
 </td>
 <td style="text-align:left;">
 bigint
@@ -1148,7 +1327,8 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The Person ID of the PERSON record for which the Observation Period is recorded.
+The Person ID of the PERSON record for which the Observation Period is
+recorded.
 </td>
 <td style="text-align:left;">
 </td>
@@ -1178,7 +1358,14 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 Use this date to determine the start date of the Observation Period
 </td>
 <td style="text-align:left;">
-It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#payer_plan_period">PAYER_PLAN_PERIOD</a>.
+It is often the case that the idea of Observation Periods does not exist
+in source data. In those cases, the observation_period_start_date can be
+inferred as the earliest Event date available for the Person. In
+insurance claim data, the Observation Period can be considered as the
+time period the Person is enrolled with a payer. If a Person switches
+plans but stays with the same payer, and therefore capturing of data
+continues, that change would be captured in <a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#payer_plan_period">PAYER_PLAN_PERIOD</a>.
 </td>
 <td style="text-align:left;">
 date
@@ -1202,10 +1389,15 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 observation_period_end_date
 </td>
 <td style="text-align:left;">
-Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded.
+Use this date to determine the end date of the period for which we can
+assume that all events for a Person are recorded.
 </td>
 <td style="text-align:left;">
-It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer.
+It is often the case that the idea of Observation Periods does not exist
+in source data. In those cases, the observation_period_end_date can be
+inferred as the last Event date available for the Person. In insurance
+claim data, the Observation Period can be considered as the time period
+the Person is enrolled with a payer.
 </td>
 <td style="text-align:left;">
 date
@@ -1229,10 +1421,15 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 period_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.
+This field can be used to determine the provenance of the Observation
+Period as in whether the period was determined from an insurance
+enrollment file, EHR healthcare encounters, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the observation_period_type_concept_id that best represents how the period was determined. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the observation_period_type_concept_id that best represents how
+the period was determined. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 Integer
@@ -1259,25 +1456,100 @@ <h3 class="tabset tabset-pills">OBSERVATION_PERIOD</h3>
 <div id="visit_occurrence" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains Events where Persons engage with the healthcare system for a duration of time. They are often also called “Encounters”. Visits are defined by a configuration of circumstances under which they occur, such as (i) whether the patient comes to a healthcare institution, the other way around, or the interaction is remote, (ii) whether and what kind of trained medical staff is delivering the service during the Visit, and (iii) whether the Visit is transient or for a longer period involving a stay in bed.</p>
+<p>This table contains Events where Persons engage with the healthcare
+system for a duration of time. They are often also called “Encounters”.
+Visits are defined by a configuration of circumstances under which they
+occur, such as (i) whether the patient comes to a healthcare
+institution, the other way around, or the interaction is remote, (ii)
+whether and what kind of trained medical staff is delivering the service
+during the Visit, and (iii) whether the Visit is transient or for a
+longer period involving a stay in bed.</p>
 <p><strong>User Guide</strong></p>
-<p>The configuration defining the Visit are described by Concepts in the Visit Domain, which form a hierarchical structure, but rolling up to generally familiar Visits adopted in most healthcare systems worldwide:</p>
+<p>The configuration defining the Visit are described by Concepts in the
+Visit Domain, which form a hierarchical structure, but rolling up to
+generally familiar Visits adopted in most healthcare systems
+worldwide:</p>
 <ul>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient Visit</a>: Person visiting hospital, at a Care Site, in bed, for duration of more than one day, with physicians and other Providers permanently available to deliver service around the clock</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency Room Visit</a>: Person visiting dedicated healthcare institution for treating emergencies, at a Care Site, within one day, with physicians and Providers permanently available to deliver service around the clock</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER followed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital institution Visit</a>: Person visiting dedicated institution for reasons of poor health, at a Care Site, long-term or permanently, with no physician but possibly other Providers permanently available to deliver service around the clock</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient Visit</a>: Person visiting dedicated ambulatory healthcare institution, at a Care Site, within one day, without bed, with physicians or medical Providers delivering service during Visit</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home Visit</a>: Provider visiting Person, without a Care Site, within one day, delivering service</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/5083">Telehealth Visit</a>: Patient engages with Provider through communication media</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/581458">Pharmacy Visit</a>: Person visiting pharmacy for dispensing of Drug, at a Care Site, within one day</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/32036">Laboratory Visit</a>: Patient visiting dedicated institution, at a Care Site, within one day, for the purpose of a Measurement.</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/581478">Ambulance Visit</a>: Person using transportation service for the purpose of initiating one of the other Visits, without a Care Site, within one day, potentially with Providers accompanying the Visit and delivering service</li>
-<li><a href="https://athena.ohdsi.org/search-terms/terms/38004193">Case Management Visit</a>: Person interacting with healthcare system, without a Care Site, within a day, with no Providers involved, for administrative purposes</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient
+Visit</a>: Person visiting hospital, at a Care Site, in bed, for
+duration of more than one day, with physicians and other Providers
+permanently available to deliver service around the clock</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency
+Room Visit</a>: Person visiting dedicated healthcare institution for
+treating emergencies, at a Care Site, within one day, with physicians
+and Providers permanently available to deliver service around the
+clock</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency
+Room and Inpatient Visit</a>: Person visiting ER followed by a
+subsequent Inpatient Visit, where Emergency department is part of
+hospital, and transition from the ER to other hospital departments is
+undefined</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital
+institution Visit</a>: Person visiting dedicated institution for reasons
+of poor health, at a Care Site, long-term or permanently, with no
+physician but possibly other Providers permanently available to deliver
+service around the clock</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient
+Visit</a>: Person visiting dedicated ambulatory healthcare institution,
+at a Care Site, within one day, without bed, with physicians or medical
+Providers delivering service during Visit</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home
+Visit</a>: Provider visiting Person, without a Care Site, within one
+day, delivering service</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/5083">Telehealth
+Visit</a>: Patient engages with Provider through communication
+media</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/581458">Pharmacy
+Visit</a>: Person visiting pharmacy for dispensing of Drug, at a Care
+Site, within one day</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/32036">Laboratory
+Visit</a>: Patient visiting dedicated institution, at a Care Site,
+within one day, for the purpose of a Measurement.</li>
+<li><a
+href="https://athena.ohdsi.org/search-terms/terms/581478">Ambulance
+Visit</a>: Person using transportation service for the purpose of
+initiating one of the other Visits, without a Care Site, within one day,
+potentially with Providers accompanying the Visit and delivering
+service</li>
+<li><a href="https://athena.ohdsi.org/search-terms/terms/38004193">Case
+Management Visit</a>: Person interacting with healthcare system, without
+a Care Site, within a day, with no Providers involved, for
+administrative purposes</li>
 </ul>
-<p>The Visit duration, or ‘length of stay’, is defined as VISIT_END_DATE - VISIT_START_DATE. For all Visits this is &lt;1 day, except Inpatient Visits and Non-hospital institution Visits. The CDM also contains the VISIT_DETAIL table where additional information about the Visit is stored, for example, transfers between units during an inpatient Visit.</p>
+<p>The Visit duration, or ‘length of stay’, is defined as VISIT_END_DATE
+- VISIT_START_DATE. For all Visits this is &lt;1 day, except Inpatient
+Visits and Non-hospital institution Visits. The CDM also contains the
+VISIT_DETAIL table where additional information about the Visit is
+stored, for example, transfers between units during an inpatient
+Visit.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Visits can be derived easily if the source data contain coding systems for Place of Service or Procedures, like CPT codes for well visits. In those cases, the codes can be looked up and mapped to a Standard Visit Concept. Otherwise, Visit Concepts have to be identified in the ETL process. This table will contain concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. Visits can be adjacent to each other, i.e. the end date of one can be identical with the start date of the other. As a consequence, more than one-day Visits or their descendants can be recorded for the same day. Multi-day visits must not overlap, i.e. share days other than start and end days. It is often the case that some logic should be written for how to define visits and how to assign Visit_Concept_Id. For example, in US claims outpatient visits that appear to occur within the time period of an inpatient visit can be rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient visits that are within one day of each other may be strung together to create one visit. It will all depend on the source data and how encounter records should be translated to visit occurrences. Providers can be associated with a Visit through the PROVIDER_ID field, or indirectly through PROCEDURE_OCCURRENCE records linked both to the VISIT and PROVIDER tables.</p>
+<p>Visits can be derived easily if the source data contain coding
+systems for Place of Service or Procedures, like CPT codes for well
+visits. In those cases, the codes can be looked up and mapped to a
+Standard Visit Concept. Otherwise, Visit Concepts have to be identified
+in the ETL process. This table will contain concepts in the Visit
+domain. These concepts are arranged in a hierarchical structure to
+facilitate cohort definitions by rolling up to generally familiar Visits
+adopted in most healthcare systems worldwide. Visits can be adjacent to
+each other, i.e. the end date of one can be identical with the start
+date of the other. As a consequence, more than one-day Visits or their
+descendants can be recorded for the same day. Multi-day visits must not
+overlap, i.e. share days other than start and end days. It is often the
+case that some logic should be written for how to define visits and how
+to assign Visit_Concept_Id. For example, in US claims outpatient visits
+that appear to occur within the time period of an inpatient visit can be
+rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient
+visits that are within one day of each other may be strung together to
+create one visit. It will all depend on the source data and how
+encounter records should be translated to visit occurrences. Providers
+can be associated with a Visit through the PROVIDER_ID field, or
+indirectly through PROCEDURE_OCCURRENCE records linked both to the VISIT
+and PROVIDER tables.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -1316,10 +1588,14 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_occurrence_id
 </td>
 <td style="text-align:left;">
-Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit.
+Use this to identify unique interactions between a person and the health
+care system. This identifier links across the other CDM event tables to
+associate events with a visit.
 </td>
 <td style="text-align:left;">
-This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.
+This should be populated by creating a unique identifier for each unique
+interaction between a person and the healthcare system where the person
+receives a medical good or service over a span of time.
 </td>
 <td style="text-align:left;">
 bigint
@@ -1369,10 +1645,17 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_concept_id
 </td>
 <td style="text-align:left;">
-This field contains a concept id representing the kind of visit, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.
+This field contains a concept id representing the kind of visit, like
+inpatient or outpatient. All concepts in this field should be standard
+and belong to the Visit domain.
 </td>
 <td style="text-align:left;">
-Populate this field based on the kind of visit that took place for the person. For example this could be “Inpatient Visit”, “Outpatient Visit”, “Ambulatory Visit”, etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide.
+Populate this field based on the kind of visit that took place for the
+person. For example this could be “Inpatient Visit”, “Outpatient Visit”,
+“Ambulatory Visit”, etc. This table will contain standard concepts in
+the Visit domain. These concepts are arranged in a hierarchical
+structure to facilitate cohort definitions by rolling up to generally
+familiar Visits adopted in most healthcare systems worldwide.
 </td>
 <td style="text-align:left;">
 integer
@@ -1398,10 +1681,15 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_start_date
 </td>
 <td style="text-align:left;">
-For inpatient visits, the start date is typically the admission date. For outpatient visits the start date and end date will be the same.
+For inpatient visits, the start date is typically the admission date.
+For outpatient visits the start date and end date will be the same.
 </td>
 <td style="text-align:left;">
-When populating visit_start_date, you should think about the patient experience to make decisions on how to define visits. In the case of an inpatient visit this should be the date the patient was admitted to the hospital or institution. In all other cases this should be the date of the patient-provider interaction.
+When populating visit_start_date, you should think about the patient
+experience to make decisions on how to define visits. In the case of an
+inpatient visit this should be the date the patient was admitted to the
+hospital or institution. In all other cases this should be the date of
+the patient-provider interaction.
 </td>
 <td style="text-align:left;">
 date
@@ -1427,7 +1715,8 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the start date of a visit, set it to midnight (00:00:0000).
+If no time is given for the start date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1454,7 +1743,20 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 For inpatient visits the end date is typically the discharge date.
 </td>
 <td style="text-align:left;">
-Visit end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them: Outpatient Visit: visit_end_datetime = visit_start_datetime Emergency Room Visit: visit_end_datetime = visit_start_datetime Inpatient Visit: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. Non-hospital institution Visits: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs. For Inpatient Visits ongoing at the date of ETL, put date of processing the data into visit_end_datetime and visit_type_concept_id with 32220 “Still patient” to identify the visit as incomplete. All other Visits: visit_end_datetime = visit_start_datetime. If this is a one-day visit the end date should match the start date.
+Visit end dates are mandatory. If end dates are not provided in the
+source there are three ways in which to derive them: Outpatient Visit:
+visit_end_datetime = visit_start_datetime Emergency Room Visit:
+visit_end_datetime = visit_start_datetime Inpatient Visit: Usually there
+is information about discharge. If not, you should be able to derive the
+end date from the sudden decline of activity or from the absence of
+inpatient procedures/drugs. Non-hospital institution Visits:
+Particularly for claims data, if end dates are not provided assume the
+visit is for the duration of month that it occurs. For Inpatient Visits
+ongoing at the date of ETL, put date of processing the data into
+visit_end_datetime and visit_type_concept_id with 32220 “Still patient”
+to identify the visit as incomplete. All other Visits:
+visit_end_datetime = visit_start_datetime. If this is a one-day visit
+the end date should match the start date.
 </td>
 <td style="text-align:left;">
 date
@@ -1480,7 +1782,8 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the end date of a visit, set it to midnight (00:00:0000).
+If no time is given for the end date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1504,10 +1807,12 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_type_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to understand the provenance of the visit record, or where the record comes from.
+Use this field to understand the provenance of the visit record, or
+where the record comes from.
 </td>
 <td style="text-align:left;">
-Populate this field based on the provenance of the visit record, as in whether it came from an EHR record or billing claim.
+Populate this field based on the provenance of the visit record, as in
+whether it came from an EHR record or billing claim.
 </td>
 <td style="text-align:left;">
 Integer
@@ -1533,10 +1838,16 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.
+There will only be one provider per visit record and the ETL document
+should clearly state how they were chosen (attending, admitting, etc.).
+If there are multiple providers associated with a visit in the source,
+this can be reflected in the event tables (CONDITION_OCCURRENCE,
+PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.
 </td>
 <td style="text-align:left;">
-If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the visit_detail table.
+If there are multiple providers associated with a visit, you will need
+to choose which one to put here. The additional providers can be stored
+in the visit_detail table.
 </td>
 <td style="text-align:left;">
 bigint
@@ -1561,7 +1872,8 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-This field provides information about the care site where the visit took place.
+This field provides information about the care site where the visit took
+place.
 </td>
 <td style="text-align:left;">
 There should only be one care site associated with a visit.
@@ -1589,10 +1901,16 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 visit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)
+This field houses the verbatim value from the source data representing
+the kind of visit that took place (inpatient, outpatient, emergency,
+etc.)
 </td>
 <td style="text-align:left;">
-If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -&gt; ER-&gt; OP. This should line up with the logic chosen to determine how visits are created.
+If there is information about the kind of visit in the source data that
+value should be stored here. If a visit is an amalgamation of visits
+from the source then use a hierarchy to choose the visit source value,
+such as IP -&gt; ER-&gt; OP. This should line up with the logic chosen
+to determine how visits are created.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1618,7 +1936,9 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. If not available set to 0.
+If the visit source value is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here. If not available set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -1643,10 +1963,13 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 admitted_from_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.
+Use this field to determine where the patient was admitted from. This
+concept is part of the visit domain and can indicate if a patient was
+admitted to the hospital from a long-term care facility, for example.
 </td>
 <td style="text-align:left;">
-If available, map the admitted_from_source_value to a standard concept in the visit domain. If not available set to 0.
+If available, map the admitted_from_source_value to a standard concept
+in the visit domain. If not available set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -1674,7 +1997,10 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+admitted from. Typically this applies only to visits that have a length
+of stay, like inpatient visits or long-term care visits.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1698,10 +2024,14 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 discharge_to_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.
+Use this field to determine where the patient was discharged to after a
+visit. This concept is part of the visit domain and can indicate if a
+patient was discharged to home or sent to a long-term care facility, for
+example.
 </td>
 <td style="text-align:left;">
-If available, map the discharge_to_source_value to a standard concept in the visit domain. If not available set to 0.
+If available, map the discharge_to_source_value to a standard concept in
+the visit domain. If not available set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -1729,7 +2059,11 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+discharged to after a visit, as in they went home or were moved to
+long-term care. Typically this applies only to visits that have a length
+of stay of a day or more.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1753,10 +2087,13 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 preceding_visit_occurrence_id
 </td>
 <td style="text-align:left;">
-Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between.
+Use this field to find the visit that occurred for the person prior to
+the given visit. There could be a few days or a few years in between.
 </td>
 <td style="text-align:left;">
-The preceding_visit_id can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
+The preceding_visit_id can be used to link a visit immediately preceding
+the current visit. Note this is not symmetrical, and there is no such
+thing as a “following_visit_id”.
 </td>
 <td style="text-align:left;">
 bigint
@@ -1782,11 +2119,38 @@ <h3 class="tabset tabset-pills">VISIT_OCCURRENCE</h3>
 <div id="visit_detail" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <p><strong>Table Description</strong></p>
-<p>The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.</p>
+<p>The VISIT_DETAIL table is an optional table used to represents
+details of each record in the parent VISIT_OCCURRENCE table. A good
+example of this would be the movement between units in a hospital during
+an inpatient stay or claim lines associated with a one insurance claim.
+For every record in the VISIT_OCCURRENCE table there may be 0 or more
+records in the VISIT_DETAIL table with a 1:n relationship where n may be
+0. The VISIT_DETAIL table is structurally very similar to
+VISIT_OCCURRENCE table and belongs to the visit domain.</p>
 <p><strong>User Guide</strong></p>
-<p>The configuration defining the Visit Detail is described by Concepts in the Visit Domain, which form a hierarchical structure. The Visit Detail record will have an associated to the Visit Occurrence record in two ways: <br> 1. The Visit Detail record will have the VISIT_OCCURRENCE_ID it is associated to 2. The VISIT_DETAIL_CONCEPT_ID will be a descendant of the VISIT_CONCEPT_ID for the Visit.</p>
+<p>The configuration defining the Visit Detail is described by Concepts
+in the Visit Domain, which form a hierarchical structure. The Visit
+Detail record will have an associated to the Visit Occurrence record in
+two ways: <br> 1. The Visit Detail record will have the
+VISIT_OCCURRENCE_ID it is associated to 2. The VISIT_DETAIL_CONCEPT_ID
+will be a descendant of the VISIT_CONCEPT_ID for the Visit.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>It is not mandatory that the VISIT_DETAIL table be filled in, but if you find that the logic to create VISIT_OCCURRENCE records includes the roll-up of multiple smaller records to create one picture of a Visit then it is a good idea to use VISIT_DETAIL. In EHR data, for example, a Person may be in the hospital but instead of one over-arching Visit their encounters are recorded as times they interacted with a health care provider. A Person in the hospital interacts with multiple providers multiple times a day so the encounters must be strung together using some heuristic (defined by the ETL) to identify the entire Visit. In this case the encounters would be considered Visit Details and the entire Visit would be the Visit Occurrence. In this example it is also possible to use the Vocabulary to distinguish Visit Details from a Visit Occurrence by setting the VISIT_CONCEPT_ID to <a href="https://athena.ohdsi.org/search-terms/terms/9201">9201</a> and the VISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicate where the patient was in the hospital at the time of care.</p>
+<p>It is not mandatory that the VISIT_DETAIL table be filled in, but if
+you find that the logic to create VISIT_OCCURRENCE records includes the
+roll-up of multiple smaller records to create one picture of a Visit
+then it is a good idea to use VISIT_DETAIL. In EHR data, for example, a
+Person may be in the hospital but instead of one over-arching Visit
+their encounters are recorded as times they interacted with a health
+care provider. A Person in the hospital interacts with multiple
+providers multiple times a day so the encounters must be strung together
+using some heuristic (defined by the ETL) to identify the entire Visit.
+In this case the encounters would be considered Visit Details and the
+entire Visit would be the Visit Occurrence. In this example it is also
+possible to use the Vocabulary to distinguish Visit Details from a Visit
+Occurrence by setting the VISIT_CONCEPT_ID to <a
+href="https://athena.ohdsi.org/search-terms/terms/9201">9201</a> and the
+VISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicate
+where the patient was in the hospital at the time of care.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -1825,10 +2189,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail.
+Use this to identify unique interactions between a person and the health
+care system. This identifier links across the other CDM event tables to
+associate events with a visit detail.
 </td>
 <td style="text-align:left;">
-This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.
+This should be populated by creating a unique identifier for each unique
+interaction between a person and the healthcare system where the person
+receives a medical good or service over a span of time.
 </td>
 <td style="text-align:left;">
 bigint
@@ -1878,10 +2246,19 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_concept_id
 </td>
 <td style="text-align:left;">
-This field contains a concept id representing the kind of visit detail, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.
+This field contains a concept id representing the kind of visit detail,
+like inpatient or outpatient. All concepts in this field should be
+standard and belong to the Visit domain.
 </td>
 <td style="text-align:left;">
-Populate this field based on the kind of visit that took place for the person. For example this could be “Inpatient Visit”, “Outpatient Visit”, “Ambulatory Visit”, etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Populate this field based on the kind of visit that took place for the
+person. For example this could be “Inpatient Visit”, “Outpatient Visit”,
+“Ambulatory Visit”, etc. This table will contain standard concepts in
+the Visit domain. These concepts are arranged in a hierarchical
+structure to facilitate cohort definitions by rolling up to generally
+familiar Visits adopted in most healthcare systems worldwide. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -1907,10 +2284,13 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_start_date
 </td>
 <td style="text-align:left;">
-This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with.
+This is the date of the start of the encounter. This may or may not be
+equal to the date of the Visit the Visit Detail is associated with.
 </td>
 <td style="text-align:left;">
-When populating visit_start_date, you should think about the patient experience to make decisions on how to define visits. Most likely this should be the date of the patient-provider interaction.
+When populating visit_start_date, you should think about the patient
+experience to make decisions on how to define visits. Most likely this
+should be the date of the patient-provider interaction.
 </td>
 <td style="text-align:left;">
 date
@@ -1936,7 +2316,8 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the start date of a visit, set it to midnight (00:00:0000).
+If no time is given for the start date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -1963,7 +2344,21 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 This the end date of the patient-provider interaction.
 </td>
 <td style="text-align:left;">
-Visit Detail end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them:&lt;br&gt; - Outpatient Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Emergency Room Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Inpatient Visit Detail: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. - Non-hospital institution Visit Details: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs.&lt;br&gt; For Inpatient Visit Details ongoing at the date of ETL, put date of processing the data into visit_detai_end_datetime and visit_detail_type_concept_id with 32220 “Still patient” to identify the visit as incomplete. All other Visits Details: visit_detail_end_datetime = visit_detail_start_datetime.
+Visit Detail end dates are mandatory. If end dates are not provided in
+the source there are three ways in which to derive them:&lt;br&gt; -
+Outpatient Visit Detail: visit_detail_end_datetime =
+visit_detail_start_datetime - Emergency Room Visit Detail:
+visit_detail_end_datetime = visit_detail_start_datetime - Inpatient
+Visit Detail: Usually there is information about discharge. If not, you
+should be able to derive the end date from the sudden decline of
+activity or from the absence of inpatient procedures/drugs. -
+Non-hospital institution Visit Details: Particularly for claims data, if
+end dates are not provided assume the visit is for the duration of month
+that it occurs.&lt;br&gt; For Inpatient Visit Details ongoing at the
+date of ETL, put date of processing the data into
+visit_detai_end_datetime and visit_detail_type_concept_id with 32220
+“Still patient” to identify the visit as incomplete. All other Visits
+Details: visit_detail_end_datetime = visit_detail_start_datetime.
 </td>
 <td style="text-align:left;">
 date
@@ -1989,7 +2384,8 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If no time is given for the end date of a visit, set it to midnight (00:00:0000).
+If no time is given for the end date of a visit, set it to midnight
+(00:00:0000).
 </td>
 <td style="text-align:left;">
 datetime
@@ -2013,10 +2409,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_type_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to understand the provenance of the visit detail record, or where the record comes from.
+Use this field to understand the provenance of the visit detail record,
+or where the record comes from.
 </td>
 <td style="text-align:left;">
-Populate this field based on the provenance of the visit detail record, as in whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Populate this field based on the provenance of the visit detail record,
+as in whether it came from an EHR record or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 Integer
@@ -2042,10 +2442,16 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-There will only be one provider per <strong>visit</strong> record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record.
+There will only be one provider per <strong>visit</strong> record and
+the ETL document should clearly state how they were chosen (attending,
+admitting, etc.). This is a typical reason for leveraging the
+VISIT_DETAIL table as even though each VISIT_DETAIL record can only have
+one provider, there is no limit to the number of VISIT_DETAIL records
+that can be associated to a VISIT_OCCURRENCE record.
 </td>
 <td style="text-align:left;">
-The additional providers associated to a Visit can be stored in this table where each VISIT_DETAIL record represents a different provider.
+The additional providers associated to a Visit can be stored in this
+table where each VISIT_DETAIL record represents a different provider.
 </td>
 <td style="text-align:left;">
 bigint
@@ -2070,7 +2476,8 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-This field provides information about the Care Site where the Visit Detail took place.
+This field provides information about the Care Site where the Visit
+Detail took place.
 </td>
 <td style="text-align:left;">
 There should only be one Care Site associated with a Visit Detail.
@@ -2098,10 +2505,16 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)
+This field houses the verbatim value from the source data representing
+the kind of visit detail that took place (inpatient, outpatient,
+emergency, etc.)
 </td>
 <td style="text-align:left;">
-If there is information about the kind of visit detail in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the VISIT_DETAIL_SOURCE_VALUE, such as IP -&gt; ER-&gt; OP. This should line up with the logic chosen to determine how visits are created.
+If there is information about the kind of visit detail in the source
+data that value should be stored here. If a visit is an amalgamation of
+visits from the source then use a hierarchy to choose the
+VISIT_DETAIL_SOURCE_VALUE, such as IP -&gt; ER-&gt; OP. This should line
+up with the logic chosen to determine how visits are created.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2127,7 +2540,9 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. If not available, map to 0.
+If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an
+OMOP supported vocabulary put the concept id representing the source
+value here. If not available, map to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -2154,7 +2569,10 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+admitted from. Typically this applies only to visits that have a length
+of stay, like inpatient visits or long-term care visits.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2178,10 +2596,15 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 admitted_from_source_value
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.
+Use this field to determine where the patient was admitted from. This
+concept is part of the visit domain and can indicate if a patient was
+admitted to the hospital from a long-term care facility, for example.
 </td>
 <td style="text-align:left;">
-If available, map the admitted_from_source_value to a standard concept in the visit domain. If not available, map to 0. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If available, map the admitted_from_source_value to a standard concept
+in the visit domain. If not available, map to 0. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2209,7 +2632,11 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating where a person was
+discharged to after a visit, as in they went home or were moved to
+long-term care. Typically this applies only to visits that have a length
+of stay of a day or more.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2233,10 +2660,16 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 discharge_to_concept_id
 </td>
 <td style="text-align:left;">
-Use this field to determine where the patient was discharged to after a visit detail record. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.
+Use this field to determine where the patient was discharged to after a
+visit detail record. This concept is part of the visit domain and can
+indicate if a patient was discharged to home or sent to a long-term care
+facility, for example.
 </td>
 <td style="text-align:left;">
-If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. If not available, set to 0. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in
+the Visit domain. If not available, set to 0. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2262,10 +2695,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 preceding_visit_detail_id
 </td>
 <td style="text-align:left;">
-Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.
+Use this field to find the visit detail that occurred for the person
+prior to the given visit detail record. There could be a few days or a
+few years in between.
 </td>
 <td style="text-align:left;">
-The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
+The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately
+preceding the current Visit Detail. Note this is not symmetrical, and
+there is no such thing as a “following_visit_id”.
 </td>
 <td style="text-align:left;">
 bigint
@@ -2290,10 +2727,14 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 visit_detail_parent_id
 </td>
 <td style="text-align:left;">
-Use this field to find the visit detail that subsumes the given visit detail record. This is used in the case that a visit detail record needs to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.
+Use this field to find the visit detail that subsumes the given visit
+detail record. This is used in the case that a visit detail record needs
+to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.
 </td>
 <td style="text-align:left;">
-If there are multiple nested levels to how Visits are represented in the source, the VISIT_DETAIL_PARENT_ID can be used to record this relationship.
+If there are multiple nested levels to how Visits are represented in the
+source, the VISIT_DETAIL_PARENT_ID can be used to record this
+relationship.
 </td>
 <td style="text-align:left;">
 bigint
@@ -2344,14 +2785,47 @@ <h3 class="tabset tabset-pills">VISIT_DETAIL</h3>
 </tbody>
 </table>
 </div>
-<div id="condition_occurrence" class="section level3 tabset tabset-pills">
+<div id="condition_occurrence"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.</p>
+<p>This table contains records of Events of a Person suggesting the
+presence of a disease or medical condition stated as a diagnosis, a
+sign, or a symptom, which is either observed by a Provider or reported
+by the patient.</p>
 <p><strong>User Guide</strong></p>
-<p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype definitions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p>
+<p>Conditions are defined by Concepts from the Condition domain, which
+form a complex hierarchy. As a result, the same Person with the same
+disease may have multiple Condition records, which belong to the same
+hierarchical family. Most Condition records are mapped from diagnostic
+codes, but recorded signs, symptoms and summary descriptions also
+contribute to this table. Rule out diagnoses should not be recorded in
+this table, but in reality their negating nature is not always captured
+in the source data, and other precautions must be taken when when
+identifying Persons who should suffer from the recorded Condition.
+Record all conditions as they exist in the source data. Any decisions
+about diagnosis/phenotype definitions would be done through cohort
+specifications. These cohorts can be housed in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a>
+table. Conditions span a time interval from start to end, but are
+typically recorded as single snapshot records with no end date. The
+reason is twofold: (i) At the time of the recording the duration is not
+known and later not recorded, and (ii) the Persons typically cease
+interacting with the healthcare system when they feel better, which
+leads to incomplete capture of resolved Conditions. The <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a>
+table addresses this issue. Family history and past diagnoses (‘history
+of’) are not recorded in this table. Instead, they are listed in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a>
+table. Codes written in the process of establishing the diagnosis, such
+as ‘question of’ of and ‘rule out’, should not represented here.
+Instead, they should be recorded in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a>
+table, if they are used for analyses. However, this information is not
+always available.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.</p>
+<p>Source codes and source text fields mapped to Standard Concepts of
+the Condition Domain have to be recorded here.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -2390,10 +2864,16 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_occurrence_id
 </td>
 <td style="text-align:left;">
-The unique key given to a condition record for a person. Refer to the ETL for how duplicate conditions during the same visit were handled.
+The unique key given to a condition record for a person. Refer to the
+ETL for how duplicate conditions during the same visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a condition present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same condition within the same visit. It is valid to keep these duplicates and assign them individual, unique, CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be handled.
+Each instance of a condition present in the source data should be
+assigned this unique key. In some cases, a person can have multiple
+records of the same condition within the same visit. It is valid to keep
+these duplicates and assign them individual, unique,
+CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be
+handled.
 </td>
 <td style="text-align:left;">
 bigint
@@ -2444,10 +2924,16 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_concept_id
 </td>
 <td style="text-align:left;">
-The CONDITION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a condition
+The CONDITION_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies. This is the standard
+concept mapped from the source value which represents a condition
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records whose source values map to concepts with a domain of “Condition” should go in this table. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Condition&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records
+whose source values map to concepts with a domain of “Condition” should
+go in this table. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Condition&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2476,7 +2962,10 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 Use this date to determine the start date of the condition
 </td>
 <td style="text-align:left;">
-Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE.
+Most often data sources do not have the idea of a start date for a
+condition. Rather, if a source only has one date associated with a
+condition record it is acceptable to use that date for both the
+CONDITION_START_DATE and the CONDITION_END_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -2502,7 +2991,8 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+If a source does not specify datetime the convention is to set the time
+to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -2529,7 +3019,10 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 Use this date to determine the end date of the condition
 </td>
 <td style="text-align:left;">
-Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE.
+Most often data sources do not have the idea of a start date for a
+condition. Rather, if a source only has one date associated with a
+condition record it is acceptable to use that date for both the
+CONDITION_START_DATE and the CONDITION_END_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -2555,7 +3048,8 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+If a source does not specify datetime the convention is to set the time
+to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -2579,10 +3073,15 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Condition
+record, as in whether the condition was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the condition_type_concept_id that best represents the provenance of the record. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the condition_type_concept_id that best represents the provenance
+of the record. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2608,10 +3107,18 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_status_concept_id
 </td>
 <td style="text-align:left;">
-This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others.
+This concept represents the point during the visit the diagnosis was
+given (admitting diagnosis, final diagnosis), whether the diagnosis was
+determined due to laboratory findings, if the diagnosis was
+exclusionary, or if it was a preliminary diagnosis, among others.
 </td>
 <td style="text-align:left;">
-Choose the Concept in the Condition Status domain that best represents the point during the visit when the diagnosis was given. These can include admitting diagnosis, principal diagnosis, and secondary diagnosis. If not available, set to 0. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the Concept in the Condition Status domain that best represents
+the point during the visit when the diagnosis was given. These can
+include admitting diagnosis, principal diagnosis, and secondary
+diagnosis. If not available, set to 0. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2636,10 +3143,13 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 stop_reason
 </td>
 <td style="text-align:left;">
-The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring.
+The Stop Reason indicates why a Condition is no longer valid with
+respect to the purpose within the source data. Note that a Stop Reason
+does not necessarily imply that the condition is no longer occurring.
 </td>
 <td style="text-align:left;">
-This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist.
+This information is often not populated in source data and it is a valid
+etl choice to leave it blank if the information does not exist.
 </td>
 <td style="text-align:left;">
 varchar(20)
@@ -2663,10 +3173,14 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with condition record, e.g. the provider who made the diagnosis or the provider who recorded the symptom.
+The provider associated with condition record, e.g. the provider who
+made the diagnosis or the provider who recorded the symptom.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record, for
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 bigint
@@ -2694,7 +3208,13 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 The visit during which the condition occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If a CONDITION_START_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE record.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If a CONDITION_START_DATE occurs within the
+start and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE
+record.
 </td>
 <td style="text-align:left;">
 bigint
@@ -2719,7 +3239,11 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the condition occurred. For example, if the person was in the ICU at the time of the diagnosis the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the condition occurred. For
+example, if the person was in the ICU at the time of the diagnosis the
+VISIT_OCCURRENCE record would reflect the overall hospital stay and the
+VISIT_DETAIL record would reflect the ICU stay during the hospital
+visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -2747,10 +3271,13 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the condition that occurred. For example, this could be an ICD10 or Read code.
+This field houses the verbatim value from the source data representing
+the condition that occurred. For example, this could be an ICD10 or Read
+code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2774,10 +3301,19 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the condition source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Condition necessary for a given analytic use case. Consider using CONDITION_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the condition source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Condition
+necessary for a given analytic use case. Consider using
+CONDITION_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. If not available, set to 0.
+If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here. If not available, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -2802,10 +3338,15 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 condition_status_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the condition status.
+This field houses the verbatim value from the source data representing
+the condition status.
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating when and how a diagnosis was given to a patient. This source value is mapped to a standard concept which is stored in the CONDITION_STATUS_CONCEPT_ID field.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating when and how a
+diagnosis was given to a patient. This source value is mapped to a
+standard concept which is stored in the CONDITION_STATUS_CONCEPT_ID
+field.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -2830,11 +3371,34 @@ <h3 class="tabset tabset-pills">CONDITION_OCCURRENCE</h3>
 <div id="drug_exposure" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table captures records about the exposure to a Drug ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain biochemical effect on the metabolism. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.</p>
+<p>This table captures records about the exposure to a Drug ingested or
+otherwise introduced into the body. A Drug is a biochemical substance
+formulated in such a way that when administered to a Person it will
+exert a certain biochemical effect on the metabolism. Drugs include
+prescription and over-the-counter medicines, vaccines, and
+large-molecule biologic therapies. Radiological devices ingested or
+applied locally do not count as Drugs.</p>
 <p><strong>User Guide</strong></p>
-<p>The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.</p>
+<p>The purpose of records in this table is to indicate an exposure to a
+certain drug as best as possible. In this context a drug is defined as
+an active ingredient. Drug Exposures are defined by Concepts from the
+Drug domain, which form a complex hierarchy. As a result, one
+DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is
+a combination product. Records in this table represent prescriptions
+written, prescriptions dispensed, and drugs administered by a provider
+to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter
+on these types. This table includes additional information about the
+drug products, the quantity given, and route of administration.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs administered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p>
+<p>Information about quantity and dose is provided in a variety of
+different ways and it is important for the ETL to provide as much
+information as possible from the data. Depending on the provenance of
+the data fields may be captured differently i.e. quantity for drugs
+administered may have a separate meaning from quantity for prescriptions
+dispensed. If a patient has multiple records on the same day for the
+same drug or procedures the ETL should not de-dupe them unless there is
+probable reason to believe the item is a true data duplicate. Take note
+on how to handle refills for prescriptions written.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -2873,10 +3437,17 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_exposure_id
 </td>
 <td style="text-align:left;">
-The unique key given to records of drug dispensings or administrations for a person. Refer to the ETL for how duplicate drugs during the same visit were handled.
+The unique key given to records of drug dispensings or administrations
+for a person. Refer to the ETL for how duplicate drugs during the same
+visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a drug dispensing or administration present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same drug within the same visit. It is valid to keep these duplicates and assign them individual, unique, DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be handled.
+Each instance of a drug dispensing or administration present in the
+source data should be assigned this unique key. In some cases, a person
+can have multiple records of the same drug within the same visit. It is
+valid to keep these duplicates and assign them individual, unique,
+DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be
+handled.
 </td>
 <td style="text-align:left;">
 bigint
@@ -2900,7 +3471,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the PERSON for whom the drug dispensing or administration is recorded. This may be a system generated code.
+The PERSON_ID of the PERSON for whom the drug dispensing or
+administration is recorded. This may be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -2927,10 +3499,35 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_concept_id
 </td>
 <td style="text-align:left;">
-The DRUG_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a drug product or molecule otherwise introduced to the body. The drug concepts can have a varying degree of information about drug strength and dose. This information is relevant in the context of quantity and administration information in the subsequent fields plus strength information from the DRUG_STRENGTH table, provided as part of the standard vocabulary download.
+The DRUG_CONCEPT_ID field is recommended for primary use in analyses,
+and must be used for network studies. This is the standard concept
+mapped from the source concept id which represents a drug product or
+molecule otherwise introduced to the body. The drug concepts can have a
+varying degree of information about drug strength and dose. This
+information is relevant in the context of quantity and administration
+information in the subsequent fields plus strength information from the
+DRUG_STRENGTH table, provided as part of the standard vocabulary
+download.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should be derived either from mapping from the source concept id or by picking the drug concept representing the most amount of detail you have. Records whose source values map to standard concepts with a domain of Drug should go in this table. When the Drug Source Value of the code cannot be translated into Standard Drug Concept IDs, a Drug exposure entry is stored with only the corresponding SOURCE_CONCEPT_ID and DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the most detailed content of information is preferred during the mapping process. These are indicated in the CONCEPT_CLASS_ID field of the Concept and are recorded in the following order of precedence: ‘Branded Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical Drug Form’, and only if no other information is available ‘Ingredient’. Note: If only the drug class is known, the DRUG_CONCEPT_ID field should contain 0. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Drug&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should
+be derived either from mapping from the source concept id or by picking
+the drug concept representing the most amount of detail you have.
+Records whose source values map to standard concepts with a domain of
+Drug should go in this table. When the Drug Source Value of the code
+cannot be translated into Standard Drug Concept IDs, a Drug exposure
+entry is stored with only the corresponding SOURCE_CONCEPT_ID and
+DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the
+most detailed content of information is preferred during the mapping
+process. These are indicated in the CONCEPT_CLASS_ID field of the
+Concept and are recorded in the following order of precedence: ‘Branded
+Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug
+Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical
+Drug Form’, and only if no other information is available ‘Ingredient’.
+Note: If only the drug class is known, the DRUG_CONCEPT_ID field should
+contain 0. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Drug&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -2959,7 +3556,10 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 Use this date to determine the start date of the drug record.
 </td>
 <td style="text-align:left;">
-Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration was recorded. It is a valid ETL choice to use the date the drug was ordered as the DRUG_EXPOSURE_START_DATE.
+Valid entries include a start date of a prescription, the date a
+prescription was filled, or the date on which a Drug administration was
+recorded. It is a valid ETL choice to use the date the drug was ordered
+as the DRUG_EXPOSURE_START_DATE.
 </td>
 <td style="text-align:left;">
 date
@@ -2985,7 +3585,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -3009,10 +3610,27 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_exposure_end_date
 </td>
 <td style="text-align:left;">
-The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.
+The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for
+the patient.
 </td>
 <td style="text-align:left;">
-If this information is not explicitly available in the data, infer the end date using the following methods:/n/n 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL) 200*5/20 = 50 days. <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples by dose form</a>
+If this information is not explicitly available in the data, infer the
+end date using the following methods:/n/n 1. Start first with duration
+or days supply using the calculation drug start date + days supply -1
+day. 2. Use quantity divided by daily dose that you may obtain from the
+sig or a source field (or assumed daily dose of 1) for solid,
+indivisibile, drug products. If quantity represents ingredient amount,
+quantity divided by daily dose * concentration (from drug_strength) drug
+concept id tells you the dose form. 3. If it is an administration
+record, set drug end date equal to drug start date. If the record is a
+written prescription then set end date to start date + 29. If the record
+is a mail-order prescription set end date to start date + 89. The end
+date must be equal to or greater than the start date. Ibuprofen 20mg/mL
+oral solution concept tells us this is oral solution. Calculate duration
+as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL)
+200*5/20 = 50 days. <a
+href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples
+by dose form</a>
 </td>
 <td style="text-align:left;">
 date
@@ -3038,7 +3656,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -3062,10 +3681,12 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 verbatim_end_date
 </td>
 <td style="text-align:left;">
-This is the end date of the drug exposure as it appears in the source data, if it is given
+This is the end date of the drug exposure as it appears in the source
+data, if it is given
 </td>
 <td style="text-align:left;">
-Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable.
+Put the end date or discontinuation date as it appears from the source
+data or leave blank if unavailable.
 </td>
 <td style="text-align:left;">
 date
@@ -3089,10 +3710,16 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_type_concept_id
 </td>
 <td style="text-align:left;">
-You can use the TYPE_CONCEPT_ID to delineate between prescriptions written vs. prescriptions dispensed vs. medication history vs. patient-reported exposure, etc.
+You can use the TYPE_CONCEPT_ID to delineate between prescriptions
+written vs. prescriptions dispensed vs. medication history
+vs. patient-reported exposure, etc.
 </td>
 <td style="text-align:left;">
-Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the drug_type_concept_id that best represents the provenance of
+the record, for example whether it came from a record of a prescription
+written or physician administered drug. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3118,10 +3745,13 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 stop_reason
 </td>
 <td style="text-align:left;">
-The reason a person stopped a medication as it is represented in the source. Reasons include regimen completed, changed, removed, etc. This field will be retired in v6.0.
+The reason a person stopped a medication as it is represented in the
+source. Reasons include regimen completed, changed, removed, etc. This
+field will be retired in v6.0.
 </td>
 <td style="text-align:left;">
-This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist.
+This information is often not populated in source data and it is a valid
+etl choice to leave it blank if the information does not exist.
 </td>
 <td style="text-align:left;">
 varchar(20)
@@ -3145,7 +3775,9 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 refills
 </td>
 <td style="text-align:left;">
-This is only filled in when the record is coming from a prescription written this field is meant to represent intended refills at time of the prescription.
+This is only filled in when the record is coming from a prescription
+written this field is meant to represent intended refills at time of the
+prescription.
 </td>
 <td style="text-align:left;">
 </td>
@@ -3173,7 +3805,22 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-To find the dose form of a drug the RELATIONSHIP table can be used where the relationship_id is ‘Has dose form’. If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the DRUG_STRENGTH table the quantity should be converted to the correct unit given in DRUG_STRENGTH. For clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160. Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similar to clinical drugs. Please see <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to calculate drug dose</a> for more information.
+To find the dose form of a drug the RELATIONSHIP table can be used where
+the relationship_id is ‘Has dose form’. If liquid, quantity stands for
+the total amount dispensed or ordered of ingredient in the units given
+by the drug_strength table. If the unit from the source data does not
+align with the unit in the DRUG_STRENGTH table the quantity should be
+converted to the correct unit given in DRUG_STRENGTH. For clinical drugs
+with fixed dose forms (tablets etc.) the quantity is the number of
+units/tablets/capsules prescribed or dispensed (can be partial, but then
+only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms
+(injections) the quantity is the amount of ingredient the patient got.
+For example, if the injection is 2mg/mL but the patient got 80mL then
+quantity is reported as 160. Quantified clinical drugs with divisible
+dose forms (prefilled syringes), the quantity is the amount of
+ingredient similar to clinical drugs. Please see <a
+href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to
+calculate drug dose</a> for more information.
 </td>
 <td style="text-align:left;">
 float
@@ -3199,7 +3846,10 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Days supply of the drug. This should be the verbatim days_supply as given on the prescription. If the drug is physician administered use duration end date if given or set to 1 as default if duration is not available.
+Days supply of the drug. This should be the verbatim days_supply as
+given on the prescription. If the drug is physician administered use
+duration end date if given or set to 1 as default if duration is not
+available.
 </td>
 <td style="text-align:left;">
 integer
@@ -3223,10 +3873,12 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 sig
 </td>
 <td style="text-align:left;">
-This is the verbatim instruction for the drug as written by the provider.
+This is the verbatim instruction for the drug as written by the
+provider.
 </td>
 <td style="text-align:left;">
-Put the written out instructions for the drug as it is verbatim in the source, if available.
+Put the written out instructions for the drug as it is verbatim in the
+source, if available.
 </td>
 <td style="text-align:left;">
 varchar(MAX)
@@ -3252,7 +3904,8 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route domain.
+The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route
+domain.
 </td>
 <td style="text-align:left;">
 integer
@@ -3303,10 +3956,14 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The Provider associated with drug record, e.g. the provider who wrote the prescription or the provider who administered the drug.
+The Provider associated with drug record, e.g. the provider who wrote
+the prescription or the provider who administered the drug.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the ordering vs administering physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record, for
+example the ordering vs administering physician on an EHR record.
 </td>
 <td style="text-align:left;">
 bigint
@@ -3331,10 +3988,12 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 visit_occurrence_id
 </td>
 <td style="text-align:left;">
-The Visit during which the drug was prescribed, administered or dispensed.
+The Visit during which the drug was prescribed, administered or
+dispensed.
 </td>
 <td style="text-align:left;">
-To populate this field drug exposures must be explicitly initiated in the visit.
+To populate this field drug exposures must be explicitly initiated in
+the visit.
 </td>
 <td style="text-align:left;">
 bigint
@@ -3359,7 +4018,11 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the drug exposure occurred. For example, if the person was in the ICU at the time of the drug administration the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the drug exposure occurred. For
+example, if the person was in the ICU at the time of the drug
+administration the VISIT_OCCURRENCE record would reflect the overall
+hospital stay and the VISIT_DETAIL record would reflect the ICU stay
+during the hospital visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -3387,10 +4050,13 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the drug exposure that occurred. For example, this could be an NDC or Gemscript code.
+This field houses the verbatim value from the source data representing
+the drug exposure that occurred. For example, this could be an NDC or
+Gemscript code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Drug Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Drug Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3414,10 +4080,19 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 drug_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the drug source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Drug necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the drug source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Drug
+necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID
+instead to enable standardized analytics that can be consistent across
+the network.
 </td>
 <td style="text-align:left;">
-If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. If unavailable, set to 0.
+If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here. If unavailable, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -3442,10 +4117,14 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 route_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the drug route.
+This field houses the verbatim value from the source data representing
+the drug route.
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating when and how a drug was given to a patient. This source value is mapped to a standard concept which is stored in the ROUTE_CONCEPT_ID field.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating when and how a drug
+was given to a patient. This source value is mapped to a standard
+concept which is stored in the ROUTE_CONCEPT_ID field.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3469,10 +4148,14 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 dose_unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the dose unit of the drug given.
+This field houses the verbatim value from the source data representing
+the dose unit of the drug given.
 </td>
 <td style="text-align:left;">
-This information may be called something different in the source data but the field is meant to contain a value indicating the unit of dosage of drug given to the patient. This is an older column and will be deprecated in an upcoming version.
+This information may be called something different in the source data
+but the field is meant to contain a value indicating the unit of dosage
+of drug given to the patient. This is an older column and will be
+deprecated in an upcoming version.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3494,14 +4177,34 @@ <h3 class="tabset tabset-pills">DRUG_EXPOSURE</h3>
 </tbody>
 </table>
 </div>
-<div id="procedure_occurrence" class="section level3 tabset tabset-pills">
+<div id="procedure_occurrence"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 <p><strong>Table Description</strong></p>
-<p>This table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.</p>
+<p>This table contains records of activities or processes ordered by, or
+carried out by, a healthcare provider on the patient with a diagnostic
+or therapeutic purpose.</p>
 <p><strong>User Guide</strong></p>
-<p>Lab tests are not a procedure, if something is observed with an expected resulting amount and unit then it should be a measurement. Phlebotomy is a procedure but so trivial that it tends to be rarely captured. It can be assumed that there is a phlebotomy procedure associated with many lab tests, therefore it is unnecessary to add them as separate procedures. If the user finds the same procedure over concurrent days, it is assumed those records are part of a procedure lasting more than a day. This logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM.</p>
+<p>Lab tests are not a procedure, if something is observed with an
+expected resulting amount and unit then it should be a measurement.
+Phlebotomy is a procedure but so trivial that it tends to be rarely
+captured. It can be assumed that there is a phlebotomy procedure
+associated with many lab tests, therefore it is unnecessary to add them
+as separate procedures. If the user finds the same procedure over
+concurrent days, it is assumed those records are part of a procedure
+lasting more than a day. This logic is in lieu of the
+procedure_end_date, which will be added in a future version of the
+CDM.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>If a procedure lasts more than a day, then it should be recorded as a separate record for each day the procedure occurred, this logic is in lieu of the PROCEDURE_END_DATE, which will be added in a future version of the CDM. When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are: - Same Procedure - Same PROCEDURE_DATETIME - Same Visit Occurrence or Visit Detail - Same Provider - Same Modifier for Procedures. Source codes and source text fields mapped to Standard Concepts of the Procedure Domain have to be recorded here.</p>
+<p>If a procedure lasts more than a day, then it should be recorded as a
+separate record for each day the procedure occurred, this logic is in
+lieu of the PROCEDURE_END_DATE, which will be added in a future version
+of the CDM. When dealing with duplicate records, the ETL must determine
+whether to sum them up into one record or keep them separate. Things to
+consider are: - Same Procedure - Same PROCEDURE_DATETIME - Same Visit
+Occurrence or Visit Detail - Same Provider - Same Modifier for
+Procedures. Source codes and source text fields mapped to Standard
+Concepts of the Procedure Domain have to be recorded here.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -3540,10 +4243,16 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_occurrence_id
 </td>
 <td style="text-align:left;">
-The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled.
+The unique key given to a procedure record for a person. Refer to the
+ETL for how duplicate procedures during the same visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled.
+Each instance of a procedure occurrence in the source data should be
+assigned this unique key. In some cases, a person can have multiple
+records of the same procedure within the same visit. It is valid to keep
+these duplicates and assign them individual, unique,
+PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be
+handled.
 </td>
 <td style="text-align:left;">
 bigint
@@ -3567,7 +4276,8 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the PERSON for whom the procedure is recorded. This may be a system generated code.
+The PERSON_ID of the PERSON for whom the procedure is recorded. This may
+be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -3594,10 +4304,16 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_concept_id
 </td>
 <td style="text-align:left;">
-The PROCEDURE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a procedure
+The PROCEDURE_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies. This is the standard
+concept mapped from the source value which represents a procedure
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records whose source values map to standard concepts with a domain of “Procedure” should go in this table. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Procedure&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records
+whose source values map to standard concepts with a domain of
+“Procedure” should go in this table. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Procedure&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3626,7 +4342,10 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 Use this date to determine the date the procedure occurred.
 </td>
 <td style="text-align:left;">
-If a procedure lasts more than a day, then it should be recorded as a separate record for each day the procedure occurred, this logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM.
+If a procedure lasts more than a day, then it should be recorded as a
+separate record for each day the procedure occurred, this logic is in
+lieu of the procedure_end_date, which will be added in a future version
+of the CDM.
 </td>
 <td style="text-align:left;">
 date
@@ -3652,7 +4371,8 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -3676,10 +4396,17 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Procedure record, as in whether the procedure was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Procedure
+record, as in whether the procedure was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. If a procedure is recorded as an EHR encounter, the PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance
+of the record, for example whether it came from an EHR record or billing
+claim. If a procedure is recorded as an EHR encounter, the
+PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3705,10 +4432,18 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 modifier_concept_id
 </td>
 <td style="text-align:left;">
-The modifiers are intended to give additional information about the procedure but as of now the vocabulary is under review.
+The modifiers are intended to give additional information about the
+procedure but as of now the vocabulary is under review.
 </td>
 <td style="text-align:left;">
-It is up to the ETL to choose how to map modifiers if they exist in source data. These concepts are typically distinguished by ‘Modifier’ concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’ vocabulary). If there is more than one modifier on a record, one should be chosen that pertains to the procedure rather than provider. If not available, set to 0. <a href="https://athena.ohdsi.org/search-terms/terms?conceptClass=CPT4+Modifier&amp;conceptClass=HCPCS+Modifier&amp;vocabulary=CPT4&amp;vocabulary=HCPCS&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+It is up to the ETL to choose how to map modifiers if they exist in
+source data. These concepts are typically distinguished by ‘Modifier’
+concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’
+vocabulary). If there is more than one modifier on a record, one should
+be chosen that pertains to the procedure rather than provider. If not
+available, set to 0. <a
+href="https://athena.ohdsi.org/search-terms/terms?conceptClass=CPT4+Modifier&amp;conceptClass=HCPCS+Modifier&amp;vocabulary=CPT4&amp;vocabulary=HCPCS&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -3736,7 +4471,9 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 If the quantity value is omitted, a single procedure is assumed.
 </td>
 <td style="text-align:left;">
-If a Procedure has a quantity of ‘0’ in the source, this should default to ‘1’ in the ETL. If there is a record in the source it can be assumed the exposure occurred at least once
+If a Procedure has a quantity of ‘0’ in the source, this should default
+to ‘1’ in the ETL. If there is a record in the source it can be assumed
+the exposure occurred at least once
 </td>
 <td style="text-align:left;">
 integer
@@ -3760,10 +4497,14 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with the procedure record, e.g. the provider who performed the Procedure.
+The provider associated with the procedure record, e.g. the provider who
+performed the Procedure.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record, for
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 bigint
@@ -3791,7 +4532,13 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 The visit during which the procedure occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If a PROCEDURE_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE record.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If a PROCEDURE_DATE occurs within the start
+and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE
+record.
 </td>
 <td style="text-align:left;">
 bigint
@@ -3816,7 +4563,11 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the Procedure occurred. For example, if the Person was in the ICU at the time of the Procedure the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the Procedure occurred. For
+example, if the Person was in the ICU at the time of the Procedure the
+VISIT_OCCURRENCE record would reflect the overall hospital stay and the
+VISIT_DETAIL record would reflect the ICU stay during the hospital
+visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -3844,10 +4595,13 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the procedure that occurred. For example, this could be an CPT4 or OPCS4 code.
+This field houses the verbatim value from the source data representing
+the procedure that occurred. For example, this could be an CPT4 or OPCS4
+code.
 </td>
 <td style="text-align:left;">
-Use this value to look up the source concept id and then map the source concept id to a standard concept id.
+Use this value to look up the source concept id and then map the source
+concept id to a standard concept id.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -3871,10 +4625,19 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 procedure_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the procedure source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Procedure necessary for a given analytic use case. Consider using PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the procedure source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Procedure
+necessary for a given analytic use case. Consider using
+PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. If not available, set to 0.
+If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here. If not available, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -3926,11 +4689,21 @@ <h3 class="tabset tabset-pills">PROCEDURE_OCCURRENCE</h3>
 <div id="device_exposure" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <p><strong>Table Description</strong></p>
-<p>The Device domain captures information about a person’s exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).</p>
+<p>The Device domain captures information about a person’s exposure to a
+foreign physical object or instrument which is used for diagnostic or
+therapeutic purposes through a mechanism beyond chemical action. Devices
+include implantable objects (e.g. pacemakers, stents, artificial
+joints), medical equipment and supplies (e.g. bandages, crutches,
+syringes), other instruments used in medical procedures (e.g. sutures,
+defibrillators) and material used in clinical care (e.g. adhesives, body
+material, dental material, surgical material).</p>
 <p><strong>User Guide</strong></p>
-<p>The distinction between Devices or supplies and Procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.</p>
+<p>The distinction between Devices or supplies and Procedures are
+sometimes blurry, but the former are physical objects while the latter
+are actions, often to apply a Device or supply.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Source codes and source text fields mapped to Standard Concepts of the Device Domain have to be recorded here.</p>
+<p>Source codes and source text fields mapped to Standard Concepts of
+the Device Domain have to be recorded here.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -3969,10 +4742,12 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_exposure_id
 </td>
 <td style="text-align:left;">
-The unique key given to records a person’s exposure to a foreign physical object or instrument.
+The unique key given to records a person’s exposure to a foreign
+physical object or instrument.
 </td>
 <td style="text-align:left;">
-Each instance of an exposure to a foreign object or device present in the source data should be assigned this unique key.
+Each instance of an exposure to a foreign object or device present in
+the source data should be assigned this unique key.
 </td>
 <td style="text-align:left;">
 bigint
@@ -4022,7 +4797,10 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_concept_id
 </td>
 <td style="text-align:left;">
-The DEVICE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a foreign object or instrument the person was exposed to.
+The DEVICE_CONCEPT_ID field is recommended for primary use in analyses,
+and must be used for network studies. This is the standard concept
+mapped from the source concept id which represents a foreign object or
+instrument the person was exposed to.
 </td>
 <td style="text-align:left;">
 The CONCEPT_ID that the DEVICE_SOURCE_VALUE maps to.
@@ -4054,7 +4832,9 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 Use this date to determine the start date of the device record.
 </td>
 <td style="text-align:left;">
-Valid entries include a start date of a procedure to implant a device, the date of a prescription for a device, or the date of device administration.
+Valid entries include a start date of a procedure to implant a device,
+the date of a prescription for a device, or the date of device
+administration.
 </td>
 <td style="text-align:left;">
 date
@@ -4080,7 +4860,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -4104,10 +4885,12 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_exposure_end_date
 </td>
 <td style="text-align:left;">
-The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended for the patient, if given.
+The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended
+for the patient, if given.
 </td>
 <td style="text-align:left;">
-Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable.
+Put the end date or discontinuation date as it appears from the source
+data or leave blank if unavailable.
 </td>
 <td style="text-align:left;">
 date
@@ -4133,7 +4916,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+If a source does not specify datetime the convention is to set the time
+to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -4157,10 +4941,15 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_type_concept_id
 </td>
 <td style="text-align:left;">
-You can use the TYPE_CONCEPT_ID to denote the provenance of the record, as in whether the record is from administrative claims or EHR. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+You can use the TYPE_CONCEPT_ID to denote the provenance of the record,
+as in whether the record is from administrative claims or EHR. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
-Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug.
+Choose the drug_type_concept_id that best represents the provenance of
+the record, for example whether it came from a record of a prescription
+written or physician administered drug.
 </td>
 <td style="text-align:left;">
 integer
@@ -4186,10 +4975,13 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 unique_device_id
 </td>
 <td style="text-align:left;">
-This is the Unique Device Identification number for devices regulated by the FDA, if given.
+This is the Unique Device Identification number for devices regulated by
+the FDA, if given.
 </td>
 <td style="text-align:left;">
-For medical devices that are regulated by the FDA, a Unique Device Identification (UDI) is provided if available in the data source and is recorded in the UNIQUE_DEVICE_ID field.
+For medical devices that are regulated by the FDA, a Unique Device
+Identification (UDI) is provided if available in the data source and is
+recorded in the UNIQUE_DEVICE_ID field.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4238,10 +5030,13 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The Provider associated with device record, e.g. the provider who wrote the prescription or the provider who implanted the device.
+The Provider associated with device record, e.g. the provider who wrote
+the prescription or the provider who implanted the device.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record.
 </td>
 <td style="text-align:left;">
 bigint
@@ -4269,7 +5064,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 The Visit during which the device was prescribed or given.
 </td>
 <td style="text-align:left;">
-To populate this field device exposures must be explicitly initiated in the visit.
+To populate this field device exposures must be explicitly initiated in
+the visit.
 </td>
 <td style="text-align:left;">
 bigint
@@ -4297,7 +5093,8 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 The Visit Detail during which the device was prescribed or given.
 </td>
 <td style="text-align:left;">
-To populate this field device exposures must be explicitly initiated in the visit detail record.
+To populate this field device exposures must be explicitly initiated in
+the visit detail record.
 </td>
 <td style="text-align:left;">
 bigint
@@ -4322,10 +5119,13 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the device exposure that occurred. For example, this could be an NDC or Gemscript code.
+This field houses the verbatim value from the source data representing
+the device exposure that occurred. For example, this could be an NDC or
+Gemscript code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Device Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4349,10 +5149,19 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 device_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the device source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Device necessary for a given analytic use case. Consider using DEVICE_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the device source value and may not
+necessarily be standard. This field is discouraged from use in analysis
+because it is not required to contain Standard Concepts that are used
+across the OHDSI community, and should only be used when Standard
+Concepts do not adequately represent the source detail for the Device
+necessary for a given analytic use case. Consider using
+DEVICE_CONCEPT_ID instead to enable standardized analytics that can be
+consistent across the network.
 </td>
 <td style="text-align:left;">
-If the DEVICE_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. If unavailable, set to 0.
+If the DEVICE_SOURCE_VALUE is coded in the source data using an OMOP
+supported vocabulary put the concept id representing the source value
+here. If unavailable, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -4378,11 +5187,47 @@ <h3 class="tabset tabset-pills">DEVICE_EXPOSURE</h3>
 <div id="measurement" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <p><strong>Table Description</strong></p>
-<p>The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a PROCEDURE_OCCURRENCE record for each measurement if one does not exist in the source data. Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. If there is no result, it is assumed that the lab test was conducted but the result was not captured.</p>
+<p>The MEASUREMENT table contains records of Measurements,
+i.e. structured values (numerical or categorical) obtained through
+systematic and standardized examination or testing of a Person or
+Person’s sample. The MEASUREMENT table contains both orders and results
+of such Measurements as laboratory tests, vital signs, quantitative
+findings from pathology reports, etc. Measurements are stored as
+attribute value pairs, with the attribute as the Measurement Concept and
+the value representing the result. The value can be a Concept (stored in
+VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit
+(UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in
+the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a
+PROCEDURE_OCCURRENCE record for each measurement if one does not exist
+in the source data. Measurements differ from Observations in that they
+require a standardized test or some other activity to generate a
+quantitative or qualitative result. If there is no result, it is assumed
+that the lab test was conducted but the result was not captured.</p>
 <p><strong>User Guide</strong></p>
-<p>Measurements are predominately lab tests with a few exceptions, like blood pressure or function tests. Results are given in the form of a value and unit combination. When investigating measurements, look for operator_concept_ids (&lt;, &gt;, etc.).</p>
+<p>Measurements are predominately lab tests with a few exceptions, like
+blood pressure or function tests. Results are given in the form of a
+value and unit combination. When investigating measurements, look for
+operator_concept_ids (&lt;, &gt;, etc.).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Only records where the source value maps to a Concept in the measurement domain should be included in this table. Even though each Measurement always has a result, the fields VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are not mandatory as often the result is not given in the source data. When the result is not known, the Measurement record represents just the fact that the corresponding Measurement was carried out, which in itself is already useful information for some use cases. For some Measurement Concepts, the result is included in the test. For example, ICD10 CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/45548980">45548980</a> ‘Abnormal level of unspecified serum enzyme’ indicates a Measurement and the result (abnormal). In those situations, the CONCEPT_RELATIONSHIP table in addition to the ‘Maps to’ record contains a second record with the relationship_id set to ‘Maps to value’. In this example, the ‘Maps to’ relationship directs to <a href="https://athena.ohdsi.org/search-terms/terms/4046263">4046263</a> ‘Enzyme measurement’ as well as a ‘Maps to value’ record to <a href="https://athena.ohdsi.org/search-terms/terms/4135493">4135493</a> ‘Abnormal’.</p>
+<p>Only records where the source value maps to a Concept in the
+measurement domain should be included in this table. Even though each
+Measurement always has a result, the fields VALUE_AS_NUMBER and
+VALUE_AS_CONCEPT_ID are not mandatory as often the result is not given
+in the source data. When the result is not known, the Measurement record
+represents just the fact that the corresponding Measurement was carried
+out, which in itself is already useful information for some use cases.
+For some Measurement Concepts, the result is included in the test. For
+example, ICD10 CONCEPT_ID <a
+href="https://athena.ohdsi.org/search-terms/terms/45548980">45548980</a>
+‘Abnormal level of unspecified serum enzyme’ indicates a Measurement and
+the result (abnormal). In those situations, the CONCEPT_RELATIONSHIP
+table in addition to the ‘Maps to’ record contains a second record with
+the relationship_id set to ‘Maps to value’. In this example, the ‘Maps
+to’ relationship directs to <a
+href="https://athena.ohdsi.org/search-terms/terms/4046263">4046263</a>
+‘Enzyme measurement’ as well as a ‘Maps to value’ record to <a
+href="https://athena.ohdsi.org/search-terms/terms/4135493">4135493</a>
+‘Abnormal’.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -4421,10 +5266,15 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_id
 </td>
 <td style="text-align:left;">
-The unique key given to a Measurement record for a Person. Refer to the ETL for how duplicate Measurements during the same Visit were handled.
+The unique key given to a Measurement record for a Person. Refer to the
+ETL for how duplicate Measurements during the same Visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of a measurement present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same measurement within the same visit. It is valid to keep these duplicates and assign them individual, unique, MEASUREMENT_IDs, though it is up to the ETL how they should be handled.
+Each instance of a measurement present in the source data should be
+assigned this unique key. In some cases, a person can have multiple
+records of the same measurement within the same visit. It is valid to
+keep these duplicates and assign them individual, unique,
+MEASUREMENT_IDs, though it is up to the ETL how they should be handled.
 </td>
 <td style="text-align:left;">
 bigint
@@ -4448,7 +5298,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the PERSON for whom the measurement is recorded. This may be a system generated code.
+The PERSON_ID of the PERSON for whom the measurement is recorded. This
+may be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -4475,10 +5326,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_concept_id
 </td>
 <td style="text-align:left;">
-The MEASUREMENT_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
+The MEASUREMENT_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain of “Measurement” should go in this table.
+The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only
+records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain
+of “Measurement” should go in this table.
 </td>
 <td style="text-align:left;">
 integer
@@ -4507,7 +5361,9 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 Use this date to determine the date of the measurement.
 </td>
 <td style="text-align:left;">
-If there are multiple dates in the source data associated with a record such as order_date, draw_date, and result_date, choose the one that is closest to the date the sample was drawn from the patient.
+If there are multiple dates in the source data associated with a record
+such as order_date, draw_date, and result_date, choose the one that is
+closest to the date the sample was drawn from the patient.
 </td>
 <td style="text-align:left;">
 date
@@ -4533,7 +5389,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
+This is not required, though it is in v6. If a source does not specify
+datetime the convention is to set the time to midnight (00:00:0000)
 </td>
 <td style="text-align:left;">
 datetime
@@ -4559,7 +5416,8 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is present for backwards compatibility and will be deprecated in an upcoming version.
+This is present for backwards compatibility and will be deprecated in an
+upcoming version.
 </td>
 <td style="text-align:left;">
 varchar(10)
@@ -4583,10 +5441,16 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Measurement record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Measurement
+record, as in whether the measurement was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the
+provenance of the record, for example whether it came from an EHR record
+or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -4612,10 +5476,18 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 operator_concept_id
 </td>
 <td style="text-align:left;">
-The meaning of Concept <a href="https://athena.ohdsi.org/search-terms/terms/4172703">4172703</a> for ‘=’ is identical to omission of a OPERATOR_CONCEPT_ID value. Since the use of this field is rare, it’s important when devising analyses to not to forget testing for the content of this field for values different from =.
+The meaning of Concept <a
+href="https://athena.ohdsi.org/search-terms/terms/4172703">4172703</a>
+for ‘=’ is identical to omission of a OPERATOR_CONCEPT_ID value. Since
+the use of this field is rare, it’s important when devising analyses to
+not to forget testing for the content of this field for values different
+from =.
 </td>
 <td style="text-align:left;">
-Operators are &lt;, &lt;=, =, &gt;=, &gt; and these concepts belong to the ‘Meas Value Operator’ domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Operators are &lt;, &lt;=, =, &gt;=, &gt; and these concepts belong to
+the ‘Meas Value Operator’ domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -4640,10 +5512,29 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 value_as_number
 </td>
 <td style="text-align:left;">
-This is the numerical value of the Result of the Measurement, if available. Note that measurements such as blood pressures will be split into their component parts i.e. one record for systolic, one record for diastolic.
+This is the numerical value of the Result of the Measurement, if
+available. Note that measurements such as blood pressures will be split
+into their component parts i.e. one record for systolic, one record for
+diastolic.
 </td>
 <td style="text-align:left;">
-If there is a negative value coming from the source, set the VALUE_AS_NUMBER to NULL, with the exception of the following Measurements (listed as LOINC codes):&lt;br&gt;- <a href="https://athena.ohdsi.org/search-terms/terms/3003396">1925-7</a> Base excess in Arterial blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3002032">1927-3</a> Base excess in Venous blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3006277">8632-2</a> QRS-Axis - <a href="https://athena.ohdsi.org/search-terms/terms/3012501">11555-0</a> Base excess in Blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3003129">1926-5</a> Base excess in Capillary blood by calculation - <a href="https://athena.ohdsi.org/search-terms/terms/3004959">28638-5</a> Base excess in Arterial cord blood by calculation <a href="https://athena.ohdsi.org/search-terms/terms/3007435">28639-3</a> Base excess in Venous cord blood by calculation
+If there is a negative value coming from the source, set the
+VALUE_AS_NUMBER to NULL, with the exception of the following
+Measurements (listed as LOINC codes):&lt;br&gt;- <a
+href="https://athena.ohdsi.org/search-terms/terms/3003396">1925-7</a>
+Base excess in Arterial blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3002032">1927-3</a>
+Base excess in Venous blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3006277">8632-2</a>
+QRS-Axis - <a
+href="https://athena.ohdsi.org/search-terms/terms/3012501">11555-0</a>
+Base excess in Blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3003129">1926-5</a>
+Base excess in Capillary blood by calculation - <a
+href="https://athena.ohdsi.org/search-terms/terms/3004959">28638-5</a>
+Base excess in Arterial cord blood by calculation <a
+href="https://athena.ohdsi.org/search-terms/terms/3007435">28639-3</a>
+Base excess in Venous cord blood by calculation
 </td>
 <td style="text-align:left;">
 float
@@ -4667,10 +5558,16 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 value_as_concept_id
 </td>
 <td style="text-align:left;">
-If the raw data gives a categorial result for measurements those values are captured and mapped to standard concepts in the ‘Meas Value’ domain.
+If the raw data gives a categorial result for measurements those values
+are captured and mapped to standard concepts in the ‘Meas Value’ domain.
 </td>
 <td style="text-align:left;">
-If the raw data provides categorial results as well as continuous results for measurements, it is a valid ETL choice to preserve both values. The continuous value should go in the VALUE_AS_NUMBER field and the categorical value should be mapped to a standard concept in the ‘Meas Value’ domain and put in the VALUE_AS_CONCEPT_ID field. This is also the destination for the ‘Maps to value’ relationship.
+If the raw data provides categorial results as well as continuous
+results for measurements, it is a valid ETL choice to preserve both
+values. The continuous value should go in the VALUE_AS_NUMBER field and
+the categorical value should be mapped to a standard concept in the
+‘Meas Value’ domain and put in the VALUE_AS_CONCEPT_ID field. This is
+also the destination for the ‘Maps to value’ relationship.
 </td>
 <td style="text-align:left;">
 integer
@@ -4695,10 +5592,16 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 unit_concept_id
 </td>
 <td style="text-align:left;">
-There is currently no recommended unit for individual measurements, i.e. it is not mandatory to represent Hemoglobin a1C measurements as a percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit domain that best represents the unit as given in the source data.
+There is currently no recommended unit for individual measurements,
+i.e. it is not mandatory to represent Hemoglobin a1C measurements as a
+percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in
+the Unit domain that best represents the unit as given in the source
+data.
 </td>
 <td style="text-align:left;">
-There is no standardization requirement for units associated with MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to choose the most plausible unit.
+There is no standardization requirement for units associated with
+MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to
+choose the most plausible unit.
 </td>
 <td style="text-align:left;">
 integer
@@ -4724,10 +5627,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 range_low
 </td>
 <td style="text-align:left;">
-Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and should remain NULL if not given.
+Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are
+provided by the source and should remain NULL if not given.
 </td>
 <td style="text-align:left;">
-If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the RANGE_HIGH and RANGE_LOW fields. This should be set to NULL if not provided.
+If reference ranges for upper and lower limit of normal as provided
+(typically by a laboratory) these are stored in the RANGE_HIGH and
+RANGE_LOW fields. This should be set to NULL if not provided.
 </td>
 <td style="text-align:left;">
 float
@@ -4751,10 +5657,13 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 range_high
 </td>
 <td style="text-align:left;">
-Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and should remain NULL if not given.
+Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are
+provided by the source and should remain NULL if not given.
 </td>
 <td style="text-align:left;">
-If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the RANGE_HIGH and RANGE_LOW fields. This should be set to NULL if not provided.
+If reference ranges for upper and lower limit of normal as provided
+(typically by a laboratory) these are stored in the RANGE_HIGH and
+RANGE_LOW fields. This should be set to NULL if not provided.
 </td>
 <td style="text-align:left;">
 float
@@ -4778,10 +5687,14 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with measurement record, e.g. the provider who ordered the test or the provider who recorded the result.
+The provider associated with measurement record, e.g. the provider who
+ordered the test or the provider who recorded the result.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record. For
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 bigint
@@ -4809,7 +5722,15 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 The visit during which the Measurement occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If a MEASUREMENT_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a measurement is related to a visit explicitly in the source data, it is possible that the result date of the Measurement falls outside of the bounds of the Visit dates.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If a MEASUREMENT_DATE occurs within the start
+and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a
+measurement is related to a visit explicitly in the source data, it is
+possible that the result date of the Measurement falls outside of the
+bounds of the Visit dates.
 </td>
 <td style="text-align:left;">
 bigint
@@ -4834,7 +5755,10 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the Measurement occurred. For
+example, if the Person was in the ICU at the time the VISIT_OCCURRENCE
+record would reflect the overall hospital stay and the VISIT_DETAIL
+record would reflect the ICU stay during the hospital visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -4862,10 +5786,14 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the Measurement that occurred. For example, this could be an ICD10 or Read code.
+This field houses the verbatim value from the source data representing
+the Measurement that occurred. For example, this could be an ICD10 or
+Read code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Measurement Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Measurement Concept in the
+Standardized Vocabularies and the original code is stored here for
+reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4889,10 +5817,19 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 measurement_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the MEASUREMENT_SOURCE_VALUE and may
+not necessarily be standard. This field is discouraged from use in
+analysis because it is not required to contain Standard Concepts that
+are used across the OHDSI community, and should only be used when
+Standard Concepts do not adequately represent the source detail for the
+Measurement necessary for a given analytic use case. Consider using
+MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the MEASUREMENT_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. If not available, set to 0.
+If the MEASUREMENT_SOURCE_VALUE is coded in the source data using an
+OMOP supported vocabulary put the concept id representing the source
+value here. If not available, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -4917,10 +5854,12 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the unit of the Measurement that occurred.
+This field houses the verbatim value from the source data representing
+the unit of the Measurement that occurred.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4944,10 +5883,14 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 value_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim result value of the Measurement from the source data .
+This field houses the verbatim result value of the Measurement from the
+source data .
 </td>
 <td style="text-align:left;">
-If both a continuous and categorical result are given in the source data such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both included, store the verbatim value that was mapped to VALUE_AS_CONCEPT_ID here.
+If both a continuous and categorical result are given in the source data
+such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both
+included, store the verbatim value that was mapped to
+VALUE_AS_CONCEPT_ID here.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -4972,11 +5915,49 @@ <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <div id="observation" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">OBSERVATION</h3>
 <p><strong>Table Description</strong></p>
-<p>The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here. <strong>New to CDM v6.0</strong> An Observation can now be linked to other records in the CDM instance using the fields OBSERVATION_EVENT_ID and OBS_EVENT_FIELD_CONCEPT_ID. To link another record to an Observation, the primary key goes in OBSERVATION_EVENT_ID (CONDITION_OCCURRENCE_ID, DRUG_EXPOSURE_ID, etc.) and the Concept representing the field where the OBSERVATION_EVENT_ID was taken from go in the OBS_EVENT_FIELD_CONCEPT_ID. For example, a CONDITION_OCCURRENCE of Asthma might be linked to an Observation of a family history of Asthma. In this case the CONDITION_OCCURRENCE_ID of the Asthma record would go in OBSERVATION_EVENT_ID of the family history record and the CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/1147127">1147127</a> would go in OBS_EVENT_FIELD_CONCEPT_ID to denote that the OBSERVATION_EVENT_ID represents a CONDITION_OCCURRENCE_ID.</p>
+<p>The OBSERVATION table captures clinical facts about a Person obtained
+in the context of examination, questioning or a procedure. Any data that
+cannot be represented by any other domains, such as social and lifestyle
+facts, medical history, family history, etc. are recorded here.
+<strong>New to CDM v6.0</strong> An Observation can now be linked to
+other records in the CDM instance using the fields OBSERVATION_EVENT_ID
+and OBS_EVENT_FIELD_CONCEPT_ID. To link another record to an
+Observation, the primary key goes in OBSERVATION_EVENT_ID
+(CONDITION_OCCURRENCE_ID, DRUG_EXPOSURE_ID, etc.) and the Concept
+representing the field where the OBSERVATION_EVENT_ID was taken from go
+in the OBS_EVENT_FIELD_CONCEPT_ID. For example, a CONDITION_OCCURRENCE
+of Asthma might be linked to an Observation of a family history of
+Asthma. In this case the CONDITION_OCCURRENCE_ID of the Asthma record
+would go in OBSERVATION_EVENT_ID of the family history record and the
+CONCEPT_ID <a
+href="https://athena.ohdsi.org/search-terms/terms/1147127">1147127</a>
+would go in OBS_EVENT_FIELD_CONCEPT_ID to denote that the
+OBSERVATION_EVENT_ID represents a CONDITION_OCCURRENCE_ID.</p>
 <p><strong>User Guide</strong></p>
-<p>Observations differ from Measurements in that they do not require a standardized test or some other activity to generate clinical fact. Typical observations are medical history, family history, the stated need for certain treatment, social circumstances, lifestyle choices, healthcare utilization patterns, etc. If the generation clinical facts requires a standardized testing such as lab testing or imaging and leads to a standardized result, the data item is recorded in the MEASUREMENT table. If the clinical fact observed determines a sign, symptom, diagnosis of a disease or other medical condition, it is recorded in the CONDITION_OCCURRENCE table. Valid Observation Concepts are not enforced to be from any domain though they still should be Standard Concepts.</p>
+<p>Observations differ from Measurements in that they do not require a
+standardized test or some other activity to generate clinical fact.
+Typical observations are medical history, family history, the stated
+need for certain treatment, social circumstances, lifestyle choices,
+healthcare utilization patterns, etc. If the generation clinical facts
+requires a standardized testing such as lab testing or imaging and leads
+to a standardized result, the data item is recorded in the MEASUREMENT
+table. If the clinical fact observed determines a sign, symptom,
+diagnosis of a disease or other medical condition, it is recorded in the
+CONDITION_OCCURRENCE table. Valid Observation Concepts are not enforced
+to be from any domain though they still should be Standard Concepts.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Records whose Source Values map to any domain besides Condition, Procedure, Drug, Measurement or Device should be stored in the Observation table. Observations can be stored as attribute value pairs, with the attribute as the Observation Concept and the value representing the clinical fact. This fact can be a Concept (stored in VALUE_AS_CONCEPT), a numerical value (VALUE_AS_NUMBER), a verbatim string (VALUE_AS_STRING), or a datetime (VALUE_AS_DATETIME). Even though Observations do not have an explicit result, the clinical fact can be stated separately from the type of Observation in the VALUE_AS_* fields. It is recommended for Observations that are suggestive statements of positive assertion should have a value of ‘Yes’ (concept_id=4188539), recorded, even though the null value is the equivalent.</p>
+<p>Records whose Source Values map to any domain besides Condition,
+Procedure, Drug, Measurement or Device should be stored in the
+Observation table. Observations can be stored as attribute value pairs,
+with the attribute as the Observation Concept and the value representing
+the clinical fact. This fact can be a Concept (stored in
+VALUE_AS_CONCEPT), a numerical value (VALUE_AS_NUMBER), a verbatim
+string (VALUE_AS_STRING), or a datetime (VALUE_AS_DATETIME). Even though
+Observations do not have an explicit result, the clinical fact can be
+stated separately from the type of Observation in the VALUE_AS_* fields.
+It is recommended for Observations that are suggestive statements of
+positive assertion should have a value of ‘Yes’ (concept_id=4188539),
+recorded, even though the null value is the equivalent.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -5015,10 +5996,12 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_id
 </td>
 <td style="text-align:left;">
-The unique key given to an Observation record for a Person. Refer to the ETL for how duplicate Observations during the same Visit were handled.
+The unique key given to an Observation record for a Person. Refer to the
+ETL for how duplicate Observations during the same Visit were handled.
 </td>
 <td style="text-align:left;">
-Each instance of an observation present in the source data should be assigned this unique key.
+Each instance of an observation present in the source data should be
+assigned this unique key.
 </td>
 <td style="text-align:left;">
 bigint
@@ -5042,7 +6025,8 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 person_id
 </td>
 <td style="text-align:left;">
-The PERSON_ID of the Person for whom the Observation is recorded. This may be a system generated code.
+The PERSON_ID of the Person for whom the Observation is recorded. This
+may be a system generated code.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5069,10 +6053,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_concept_id
 </td>
 <td style="text-align:left;">
-The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
+The OBSERVATION_CONCEPT_ID field is recommended for primary use in
+analyses, and must be used for network studies.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domains MUST go to the corresponding table.
+The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is
+no specified domain that the Concepts in this table must adhere to. The
+only rule is that records with Concepts in the Condition, Procedure,
+Drug, Measurement, or Device domains MUST go to the corresponding table.
 </td>
 <td style="text-align:left;">
 integer
@@ -5097,10 +6085,13 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_date
 </td>
 <td style="text-align:left;">
-The date of the Observation. Depending on what the Observation represents this could be the date of a lab test, the date of a survey, or the date a patient’s family history was taken.
+The date of the Observation. Depending on what the Observation
+represents this could be the date of a lab test, the date of a survey,
+or the date a patient’s family history was taken.
 </td>
 <td style="text-align:left;">
-For some observations the ETL may need to make a choice as to which date to choose.
+For some observations the ETL may need to make a choice as to which date
+to choose.
 </td>
 <td style="text-align:left;">
 date
@@ -5150,10 +6141,16 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_type_concept_id
 </td>
 <td style="text-align:left;">
-This field can be used to determine the provenance of the Observation record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.
+This field can be used to determine the provenance of the Observation
+record, as in whether the measurement was from an EHR system, insurance
+claim, registry, or other sources.
 </td>
 <td style="text-align:left;">
-Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the
+provenance of the record, for example whether it came from an EHR record
+or billing claim. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -5179,7 +6176,10 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_number
 </td>
 <td style="text-align:left;">
-This is the numerical value of the Result of the Observation, if applicable and available. It is not expected that all Observations will have numeric results, rather, this field is here to house values should they exist.
+This is the numerical value of the Result of the Observation, if
+applicable and available. It is not expected that all Observations will
+have numeric results, rather, this field is here to house values should
+they exist.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5205,7 +6205,8 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_string
 </td>
 <td style="text-align:left;">
-This is the categorical value of the Result of the Observation, if applicable and available.
+This is the categorical value of the Result of the Observation, if
+applicable and available.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5231,10 +6232,29 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_concept_id
 </td>
 <td style="text-align:left;">
-It is possible that some records destined for the Observation table have two clinical ideas represented in one source code. This is common with ICD10 codes that describe a family history of some Condition, for example. In OMOP the Vocabulary breaks these two clinical ideas into two codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the VALUE_AS_CONCEPT_ID. It is important when using the Observation table to keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID field for relevant information.
+It is possible that some records destined for the Observation table have
+two clinical ideas represented in one source code. This is common with
+ICD10 codes that describe a family history of some Condition, for
+example. In OMOP the Vocabulary breaks these two clinical ideas into two
+codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the
+VALUE_AS_CONCEPT_ID. It is important when using the Observation table to
+keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID
+field for relevant information.
 </td>
 <td style="text-align:left;">
-Note that the value of VALUE_AS_CONCEPT_ID may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the ‘Maps to’ record contains a second record with the relationship_id set to ‘Maps to value’. For example, ICD10 <a href="https://athena.ohdsi.org/search-terms/terms/45581076">Z82.4</a> ‘Family history of ischaemic heart disease and other diseases of the circulatory system’ has a ‘Maps to’ relationship to <a href="https://athena.ohdsi.org/search-terms/terms/4167217">4167217</a> ‘Family history of clinical finding’ as well as a ‘Maps to value’ record to <a href="https://athena.ohdsi.org/search-terms/terms/134057">134057</a> ‘Disorder of cardiovascular system’.
+Note that the value of VALUE_AS_CONCEPT_ID may be provided through
+mapping from a source Concept which contains the content of the
+Observation. In those situations, the CONCEPT_RELATIONSHIP table in
+addition to the ‘Maps to’ record contains a second record with the
+relationship_id set to ‘Maps to value’. For example, ICD10 <a
+href="https://athena.ohdsi.org/search-terms/terms/45581076">Z82.4</a>
+‘Family history of ischaemic heart disease and other diseases of the
+circulatory system’ has a ‘Maps to’ relationship to <a
+href="https://athena.ohdsi.org/search-terms/terms/4167217">4167217</a>
+‘Family history of clinical finding’ as well as a ‘Maps to value’ record
+to <a
+href="https://athena.ohdsi.org/search-terms/terms/134057">134057</a>
+‘Disorder of cardiovascular system’.
 </td>
 <td style="text-align:left;">
 Integer
@@ -5259,10 +6279,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 qualifier_concept_id
 </td>
 <td style="text-align:left;">
-This field contains all attributes specifying the clinical fact further, such as as degrees, severities, drug-drug interaction alerts etc.
+This field contains all attributes specifying the clinical fact further,
+such as as degrees, severities, drug-drug interaction alerts etc.
 </td>
 <td style="text-align:left;">
-Use your best judgement as to what Concepts to use here and if they are necessary to accurately represent the clinical record. There is no restriction on the domain of these Concepts, they just need to be Standard.
+Use your best judgement as to what Concepts to use here and if they are
+necessary to accurately represent the clinical record. There is no
+restriction on the domain of these Concepts, they just need to be
+Standard.
 </td>
 <td style="text-align:left;">
 integer
@@ -5287,10 +6311,15 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 unit_concept_id
 </td>
 <td style="text-align:left;">
-There is currently no recommended unit for individual observation concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit domain that best represents the unit as given in the source data.
+There is currently no recommended unit for individual observation
+concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in
+the Unit domain that best represents the unit as given in the source
+data.
 </td>
 <td style="text-align:left;">
-There is no standardization requirement for units associated with OBSERVATION_CONCEPT_IDs, however, it is the responsibility of the ETL to choose the most plausible unit.
+There is no standardization requirement for units associated with
+OBSERVATION_CONCEPT_IDs, however, it is the responsibility of the ETL to
+choose the most plausible unit.
 </td>
 <td style="text-align:left;">
 integer
@@ -5316,10 +6345,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-The provider associated with the observation record, e.g. the provider who ordered the test or the provider who recorded the result.
+The provider associated with the observation record, e.g. the provider
+who ordered the test or the provider who recorded the result.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record.
+The ETL may need to make a choice as to which PROVIDER_ID to put here.
+Based on what is available this may or may not be different than the
+provider associated with the overall VISIT_OCCURRENCE record. For
+example the admitting vs attending physician on an EHR record.
 </td>
 <td style="text-align:left;">
 bigint
@@ -5347,7 +6380,15 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 The visit during which the Observation occurred.
 </td>
 <td style="text-align:left;">
-Depending on the structure of the source data, this may have to be determined based on dates. If an OBSERVATION_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the observation record. If an observation is related to a visit explicitly in the source data, it is possible that the result date of the Observation falls outside of the bounds of the Visit dates.
+Depending on the structure of the source data, this may have to be
+determined based on dates. If an OBSERVATION_DATE occurs within the
+start and end date of a Visit it is a valid ETL choice to choose the
+VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not
+explicitly stated in the data. While not required, an attempt should be
+made to locate the VISIT_OCCURRENCE_ID of the observation record. If an
+observation is related to a visit explicitly in the source data, it is
+possible that the result date of the Observation falls outside of the
+bounds of the Visit dates.
 </td>
 <td style="text-align:left;">
 bigint
@@ -5372,7 +6413,10 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 visit_detail_id
 </td>
 <td style="text-align:left;">
-The VISIT_DETAIL record during which the Observation occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.
+The VISIT_DETAIL record during which the Observation occurred. For
+example, if the Person was in the ICU at the time the VISIT_OCCURRENCE
+record would reflect the overall hospital stay and the VISIT_DETAIL
+record would reflect the ICU stay during the hospital visit.
 </td>
 <td style="text-align:left;">
 Same rules apply as for the VISIT_OCCURRENCE_ID.
@@ -5400,10 +6444,13 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the Observation that occurred. For example, this could be an ICD10 or Read code.
+This field houses the verbatim value from the source data representing
+the Observation that occurred. For example, this could be an ICD10 or
+Read code.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5427,10 +6474,19 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_source_concept_id
 </td>
 <td style="text-align:left;">
-This is the concept representing the OBSERVATION_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Observation necessary for a given analytic use case. Consider using OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.
+This is the concept representing the OBSERVATION_SOURCE_VALUE and may
+not necessarily be standard. This field is discouraged from use in
+analysis because it is not required to contain Standard Concepts that
+are used across the OHDSI community, and should only be used when
+Standard Concepts do not adequately represent the source detail for the
+Observation necessary for a given analytic use case. Consider using
+OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can
+be consistent across the network.
 </td>
 <td style="text-align:left;">
-If the OBSERVATION_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. If not available, set to 0.
+If the OBSERVATION_SOURCE_VALUE is coded in the source data using an
+OMOP supported vocabulary put the concept id representing the source
+value here. If not available, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -5455,10 +6511,12 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the unit of the Observation that occurred.
+This field houses the verbatim value from the source data representing
+the unit of the Observation that occurred.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5482,10 +6540,12 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 qualifier_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing the qualifier of the Observation that occurred.
+This field houses the verbatim value from the source data representing
+the qualifier of the Observation that occurred.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.
+This code is mapped to a Standard Condition Concept in the Standardized
+Vocabularies and the original code is stored here for reference.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5509,10 +6569,14 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 observation_event_id
 </td>
 <td style="text-align:left;">
-If the Observation record is related to another record in the database, this field is the primary key of the linked record.
+If the Observation record is related to another record in the database,
+this field is the primary key of the linked record.
 </td>
 <td style="text-align:left;">
-Put the primary key of the linked record, if applicable, here. See the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#observation">ETL Conventions for the OBSERVATION</a> table for more details.
+Put the primary key of the linked record, if applicable, here. See the
+<a
+href="https://ohdsi.github.io/CommonDataModel/cdm60.html#observation">ETL
+Conventions for the OBSERVATION</a> table for more details.
 </td>
 <td style="text-align:left;">
 bigint
@@ -5536,10 +6600,13 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 obs_event_field_concept_id
 </td>
 <td style="text-align:left;">
-If the Observation record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from.
+If the Observation record is related to another record in the database,
+this field is the CONCEPT_ID that identifies which table the primary key
+of the linked record came from.
 </td>
 <td style="text-align:left;">
-Put the CONCEPT_ID that identifies which table and field the OBSERVATION_EVENT_ID came from.
+Put the CONCEPT_ID that identifies which table and field the
+OBSERVATION_EVENT_ID came from.
 </td>
 <td style="text-align:left;">
 integer
@@ -5564,7 +6631,8 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 value_as_datetime
 </td>
 <td style="text-align:left;">
-It is possible that some Observation records might store a result as a date value.
+It is possible that some Observation records might store a result as a
+date value.
 </td>
 <td style="text-align:left;">
 </td>
@@ -5591,17 +6659,38 @@ <h3 class="tabset tabset-pills">OBSERVATION</h3>
 <div id="note" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">NOTE</h3>
 <p><strong>Table Description</strong></p>
-<p>The NOTE table captures unstructured information that was recorded by a provider about a patient in free text (in ASCII, or preferably in UTF8 format) notes on a given date. The type of note_text is CLOB or varchar(MAX) depending on RDBMS.</p>
+<p>The NOTE table captures unstructured information that was recorded by
+a provider about a patient in free text (in ASCII, or preferably in UTF8
+format) notes on a given date. The type of note_text is CLOB or
+varchar(MAX) depending on RDBMS.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>HL7/LOINC CDO is a standard for consistent naming of documents to support a range of use cases: retrieval, organization, display, and exchange. It guides the creation of LOINC codes for clinical notes. CDO annotates each document with 5 dimensions:</p>
+<p>HL7/LOINC CDO is a standard for consistent naming of documents to
+support a range of use cases: retrieval, organization, display, and
+exchange. It guides the creation of LOINC codes for clinical notes. CDO
+annotates each document with 5 dimensions:</p>
 <ul>
-<li><strong>Kind of Document</strong>: Characterizes the general structure of the document at a macro level (e.g. Anesthesia Consent)</li>
-<li><strong>Type of Service</strong>: Characterizes the kind of service or activity (e.g. evaluations, consultations, and summaries). The notion of time sequence, e.g., at the beginning (admission) at the end (discharge) is subsumed in this axis. Example: Discharge Teaching.</li>
-<li><strong>Setting</strong>: Setting is an extension of CMS’s definitions (e.g. Inpatient, Outpatient)</li>
-<li><strong>Subject Matter Domain (SMD)</strong>: Characterizes the subject matter domain of a note (e.g. Anesthesiology)</li>
-<li><strong>Role</strong>: Characterizes the training or professional level of the author of the document, but does not break down to specialty or subspecialty (e.g. Physician) Each combination of these 5 dimensions rolls up to a unique LOINC code.</li>
+<li><strong>Kind of Document</strong>: Characterizes the general
+structure of the document at a macro level (e.g. Anesthesia
+Consent)</li>
+<li><strong>Type of Service</strong>: Characterizes the kind of service
+or activity (e.g. evaluations, consultations, and summaries). The notion
+of time sequence, e.g., at the beginning (admission) at the end
+(discharge) is subsumed in this axis. Example: Discharge Teaching.</li>
+<li><strong>Setting</strong>: Setting is an extension of CMS’s
+definitions (e.g. Inpatient, Outpatient)</li>
+<li><strong>Subject Matter Domain (SMD)</strong>: Characterizes the
+subject matter domain of a note (e.g. Anesthesiology)</li>
+<li><strong>Role</strong>: Characterizes the training or professional
+level of the author of the document, but does not break down to
+specialty or subspecialty (e.g. Physician) Each combination of these 5
+dimensions rolls up to a unique LOINC code.</li>
 </ul>
-<p>According to CDO requirements, only 2 of the 5 dimensions are required to properly annotate a document; Kind of Document and any one of the other 4 dimensions. However, not all the permutations of the CDO dimensions will necessarily yield an existing LOINC code. Each of these dimensions are contained in the OMOP Vocabulary under the domain of ‘Meas Value’ with each dimension represented as a Concept Class.</p>
+<p>According to CDO requirements, only 2 of the 5 dimensions are
+required to properly annotate a document; Kind of Document and any one
+of the other 4 dimensions. However, not all the permutations of the CDO
+dimensions will necessarily yield an existing LOINC code. Each of these
+dimensions are contained in the OMOP Vocabulary under the domain of
+‘Meas Value’ with each dimension represented as a Concept Class.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -5798,7 +6887,9 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 The provenance of the note. Most likely this will be EHR.
 </td>
 <td style="text-align:left;">
-Put the source system of the note, as in EHR record. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Put the source system of the note, as in EHR record. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -5824,10 +6915,17 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 note_class_concept_id
 </td>
 <td style="text-align:left;">
-A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note.
+A Standard Concept Id representing the HL7 LOINC Document Type
+Vocabulary classification of the note.
 </td>
 <td style="text-align:left;">
-Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">AcceptedConcepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note).
+Map the note classification to a Standard Concept. For more information
+see the ETL Conventions in the description of the NOTE table. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">AcceptedConcepts</a>.
+This Concept can alternatively be represented by concepts with the
+relationship ‘Kind of (LOINC)’ to <a
+href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a>
+(Note).
 </td>
 <td style="text-align:left;">
 integer
@@ -5907,7 +7005,10 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 This is the Concept representing the character encoding type.
 </td>
 <td style="text-align:left;">
-Put the Concept Id that represents the encoding character type here. Currently the only option is UTF-8 (<a href="https://athena.ohdsi.org/search-terms/terms/32678">32678</a>). It the note is encoded in any other type, like ASCII then put 0.
+Put the Concept Id that represents the encoding character type here.
+Currently the only option is UTF-8 (<a
+href="https://athena.ohdsi.org/search-terms/terms/32678">32678</a>). It
+the note is encoded in any other type, like ASCII then put 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -5935,7 +7036,9 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 The language of the note.
 </td>
 <td style="text-align:left;">
-Use Concepts that are descendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages).
+Use Concepts that are descendants of the concept <a
+href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a>
+(World Languages).
 </td>
 <td style="text-align:left;">
 integer
@@ -6069,7 +7172,8 @@ <h3 class="tabset tabset-pills">NOTE</h3>
 <div id="note_nlp" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <p><strong>Table Description</strong></p>
-<p>The NOTE_NLP table encodes all output of NLP on clinical notes. Each row represents a single extracted term from a note.</p>
+<p>The NOTE_NLP table encodes all output of NLP on clinical notes. Each
+row represents a single extracted term from a note.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -6162,7 +7266,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The SECTION_CONCEPT_ID should be used to represent the note section contained in the NOTE_NLP record. These concepts can be found as parts of document panels and are based on the type of note written, i.e. a discharge summary. These panels can be found as concepts with the relationship ‘Subsumes’ to CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
+The SECTION_CONCEPT_ID should be used to represent the note section
+contained in the NOTE_NLP record. These concepts can be found as parts
+of document panels and are based on the type of note written, i.e. a
+discharge summary. These panels can be found as concepts with the
+relationship ‘Subsumes’ to CONCEPT_ID <a
+href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -6319,7 +7428,8 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Name and version of the NLP system that extracted the term. Useful for data provenance.
+Name and version of the NLP system that extracted the term. Useful for
+data provenance.
 </td>
 <td style="text-align:left;">
 varchar(250)
@@ -6397,7 +7507,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Term_exists is defined as a flag that indicates if the patient actually has or had the condition. Any of the following modifiers would make Term_exists false: Negation = true Subject = [anything other than the patient] Conditional = true/li&gt; Rule_out = true Uncertain = very low certainty or any lower certainties A complete lack of modifiers would make Term_exists true.
+Term_exists is defined as a flag that indicates if the patient actually
+has or had the condition. Any of the following modifiers would make
+Term_exists false: Negation = true Subject = [anything other than the
+patient] Conditional = true/li&gt; Rule_out = true Uncertain = very low
+certainty or any lower certainties A complete lack of modifiers would
+make Term_exists true.
 </td>
 <td style="text-align:left;">
 varchar(1)
@@ -6423,7 +7538,9 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Term_temporal is to indicate if a condition is present or just in the past. The following would be past:&lt;br&gt;&lt;br&gt; - History = true - Concept_date = anything before the time of the report
+Term_temporal is to indicate if a condition is present or just in the
+past. The following would be past:&lt;br&gt;&lt;br&gt; - History = true
+- Concept_date = anything before the time of the report
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -6449,7 +7566,13 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-For the modifiers that are there, they would have to have these values:&lt;br&gt;&lt;br&gt; - Negation = false - Subject = patient - Conditional = false - Rule_out = false - Uncertain = true or high or moderate or even low (could argue about low). Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers.
+For the modifiers that are there, they would have to have these
+values:&lt;br&gt;&lt;br&gt; - Negation = false - Subject = patient -
+Conditional = false - Rule_out = false - Uncertain = true or high or
+moderate or even low (could argue about low). Term_modifiers will
+concatenate all modifiers for different types of entities (conditions,
+drugs, labs etc) into one string. Lab values will be saved as one of the
+modifiers.
 </td>
 <td style="text-align:left;">
 varchar(2000)
@@ -6474,9 +7597,12 @@ <h3 class="tabset tabset-pills">NOTE_NLP</h3>
 <div id="specimen" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <p><strong>Table Description</strong></p>
-<p>The specimen domain contains the records identifying biological samples from a person.</p>
+<p>The specimen domain contains the records identifying biological
+samples from a person.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Anatomic site is coded at the most specific level of granularity possible, such that higher level classifications can be derived using the Standardized Vocabularies.</p>
+<p>Anatomic site is coded at the most specific level of granularity
+possible, such that higher level classifications can be derived using
+the Standardized Vocabularies.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -6570,7 +7696,10 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the specimen domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the
+specimen domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -6597,7 +7726,9 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Put the source of the specimen record, as in an EHR system. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Put the source of the specimen record, as in an EHR system. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -6703,7 +7834,9 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 The unit for the quantity of the specimen.
 </td>
 <td style="text-align:left;">
-Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -6731,7 +7864,11 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 This is the site on the body where the specimen is from.
 </td>
 <td style="text-align:left;">
-Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec Anatomic Site domain. This should be coded at the lowest level of granularity <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Spec+Anatomic+Site&amp;conceptClass=Body+Structure&amp;page=4&amp;pageSize=15&amp;query=">Accepted Concepts</a>
+Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec
+Anatomic Site domain. This should be coded at the lowest level of
+granularity <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Spec+Anatomic+Site&amp;conceptClass=Body+Structure&amp;page=4&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>
 </td>
 <td style="text-align:left;">
 integer
@@ -6835,7 +7972,8 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This unit for the quantity of the specimen, as represented in the source.
+This unit for the quantity of the specimen, as represented in the
+source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -6861,7 +7999,8 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This is the site on the body where the specimen was taken from, as represented in the source.
+This is the site on the body where the specimen was taken from, as
+represented in the source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -6911,9 +8050,24 @@ <h3 class="tabset tabset-pills">SPECIMEN</h3>
 <div id="fact_relationship" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">FACT_RELATIONSHIP</h3>
 <p><strong>Table Description</strong></p>
-<p>The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains. Examples of Fact Relationships include: <a href="https://athena.ohdsi.org/search-terms/terms?domain=Relationship&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Person relationships</a> (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).</p>
+<p>The FACT_RELATIONSHIP table contains records about the relationships
+between facts stored as records in any table of the CDM. Relationships
+can be defined between facts from the same domain, or different domains.
+Examples of Fact Relationships include: <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Relationship&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Person
+relationships</a> (parent-child), care site relationships (hierarchical
+organizational structure of facilities within a health system),
+indication relationship (between drug exposures and associated
+conditions), usage relationships (of devices during the course of an
+associated procedure), or facts derived from one another (measurements
+derived from an associated specimen).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>All relationships are directional, and each relationship is represented twice symmetrically within the FACT_RELATIONSHIP table. For example, two persons if person_id = 1 is the mother of person_id = 2 two records are in the FACT_RELATIONSHIP table (all strings in fact concept_id records in the Concept table: - Person, 1, Person, 2, parent of - Person, 2, Person, 1, child of</p>
+<p>All relationships are directional, and each relationship is
+represented twice symmetrically within the FACT_RELATIONSHIP table. For
+example, two persons if person_id = 1 is the mother of person_id = 2 two
+records are in the FACT_RELATIONSHIP table (all strings in fact
+concept_id records in the Concept table: - Person, 1, Person, 2, parent
+of - Person, 2, Person, 1, child of</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7081,11 +8235,19 @@ <h3 class="tabset tabset-pills">FACT_RELATIONSHIP</h3>
 <div id="survey_conduct" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 <p><strong>Table Description</strong></p>
-<p>The SURVEY_CONDUCT table is used to store an instance of a completed survey or questionnaire.</p>
+<p>The SURVEY_CONDUCT table is used to store an instance of a completed
+survey or questionnaire.</p>
 <p><strong>User Guide</strong></p>
-<p>This table captures details of the individual questionnaire such as who completed it, when it was completed and to which patient treatment or visit it relates to (if any).</p>
+<p>This table captures details of the individual questionnaire such as
+who completed it, when it was completed and to which patient treatment
+or visit it relates to (if any).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Each SURVEY has a SURVEY_CONCEPT_ID, a concept in the CONCEPT table identifying the questionnaire e.g. EQ5D, VR12, SF12. Each questionnaire should exist in the CONCEPT table. Each SURVEY can be optionally related to a specific Visit in order to link it both to the Visit during which it was completed and any subsequent Visit where treatment was assigned based on the patient’s responses.</p>
+<p>Each SURVEY has a SURVEY_CONCEPT_ID, a concept in the CONCEPT table
+identifying the questionnaire e.g. EQ5D, VR12, SF12. Each questionnaire
+should exist in the CONCEPT table. Each SURVEY can be optionally related
+to a specific Visit in order to link it both to the Visit during which
+it was completed and any subsequent Visit where treatment was assigned
+based on the patient’s responses.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7180,7 +8342,11 @@ <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 This is the Concept that represents the survey that was completed.
 </td>
 <td style="text-align:left;">
-Put the CONCEPT_ID that identifies the survey that the Person completed. There is no specified domain for this table but the concept class ‘staging/scales’ contains many common surveys. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Staging+%2F+Scales&amp;page=5&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Put the CONCEPT_ID that identifies the survey that the Person completed.
+There is no specified domain for this table but the concept class
+‘staging/scales’ contains many common surveys. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Staging+%2F+Scales&amp;page=5&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -7312,7 +8478,9 @@ <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 This is the Provider associated with the survey completion.
 </td>
 <td style="text-align:left;">
-The ETL may need to make a choice as to which Provider to put here. This could either be the provider that ordered the survey or the provider who observed the completion of the survey.
+The ETL may need to make a choice as to which Provider to put here. This
+could either be the provider that ordered the survey or the provider who
+observed the completion of the survey.
 </td>
 <td style="text-align:left;">
 bigint
@@ -7337,10 +8505,12 @@ <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 assisted_concept_id
 </td>
 <td style="text-align:left;">
-This is a Concept that represents whether the survey was completed with assistance or independently.
+This is a Concept that represents whether the survey was completed with
+assistance or independently.
 </td>
 <td style="text-align:left;">
-There is no specific domain or class for this field, just choose the one that best represents the value given in the source.
+There is no specific domain or class for this field, just choose the one
+that best represents the value given in the source.
 </td>
 <td style="text-align:left;">
 integer
@@ -7365,10 +8535,13 @@ <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 respondent_type_concept_id
 </td>
 <td style="text-align:left;">
-This is a Concept that represents who actually recorded the answers to the survey. For example, this could be the patient or a research associate.
+This is a Concept that represents who actually recorded the answers to
+the survey. For example, this could be the patient or a research
+associate.
 </td>
 <td style="text-align:left;">
-There is no specific domain or class for this field, just choose the one that best represents the value given in the source.
+There is no specific domain or class for this field, just choose the one
+that best represents the value given in the source.
 </td>
 <td style="text-align:left;">
 integer
@@ -7393,10 +8566,12 @@ <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 timing_concept_id
 </td>
 <td style="text-align:left;">
-This is a Concept that represents the timing of the survey. For example this could be the 3-month follow-up appointment.
+This is a Concept that represents the timing of the survey. For example
+this could be the 3-month follow-up appointment.
 </td>
 <td style="text-align:left;">
-There is no specific domain or class for this field, just choose the one that best represents the value given in the source.
+There is no specific domain or class for this field, just choose the one
+that best represents the value given in the source.
 </td>
 <td style="text-align:left;">
 integer
@@ -7424,7 +8599,9 @@ <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 This Concept represents how the responses were collected.
 </td>
 <td style="text-align:left;">
-Use the concepts that have the relationship ‘Has Answer’ with the CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/42529316">42529316</a>.
+Use the concepts that have the relationship ‘Has Answer’ with the
+CONCEPT_ID <a
+href="https://athena.ohdsi.org/search-terms/terms/42529316">42529316</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -7449,7 +8626,9 @@ <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 assisted_source_value
 </td>
 <td style="text-align:left;">
-Source value representing whether patient required assistance to complete the survey. Example: ‘Completed without assistance’, ‘Completed with assistance’.
+Source value representing whether patient required assistance to
+complete the survey. Example: ‘Completed without assistance’, ‘Completed
+with assistance’.
 </td>
 <td style="text-align:left;">
 </td>
@@ -7501,7 +8680,8 @@ <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 timing_source_value
 </td>
 <td style="text-align:left;">
-Text string representing the timing of the survey. Example: Baseline, 6-month follow-up.
+Text string representing the timing of the survey. Example: Baseline,
+6-month follow-up.
 </td>
 <td style="text-align:left;">
 </td>
@@ -7738,7 +8918,8 @@ <h3 class="tabset tabset-pills">SURVEY_CONDUCT</h3>
 response_visit_occurrence_id
 </td>
 <td style="text-align:left;">
-The Visit during which any treatment related to the Survey was carried out.
+The Visit during which any treatment related to the Survey was carried
+out.
 </td>
 <td style="text-align:left;">
 </td>
@@ -7769,9 +8950,18 @@ <h2><strong>Health System Data Tables</strong></h2>
 <div id="location" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">LOCATION</h3>
 <p><strong>Table Description</strong></p>
-<p>The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites. <strong>New to CDM v6.0</strong> The LOCATION table now includes latitude and longitude.</p>
+<p>The LOCATION table represents a generic way to capture physical
+location or address information of Persons and Care Sites. <strong>New
+to CDM v6.0</strong> The LOCATION table now includes latitude and
+longitude.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Each address or Location is unique and is present only once in the table. Locations do not contain names, such as the name of a hospital. In order to construct a full address that can be used in the postal service, the address information from the Location needs to be combined with information from the Care Site. For standardized geospatial visualization and analysis, addresses need to be, at the minimum be geocoded into latitude and longitude.</p>
+<p>Each address or Location is unique and is present only once in the
+table. Locations do not contain names, such as the name of a hospital.
+In order to construct a full address that can be used in the postal
+service, the address information from the Location needs to be combined
+with information from the Care Site. For standardized geospatial
+visualization and analysis, addresses need to be, at the minimum be
+geocoded into latitude and longitude.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -7813,7 +9003,8 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 The unique key given to a unique Location.
 </td>
 <td style="text-align:left;">
-Each instance of a Location in the source data should be assigned this unique key.
+Each instance of a Location in the source data should be assigned this
+unique key.
 </td>
 <td style="text-align:left;">
 bigint
@@ -7941,7 +9132,12 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Zip codes are handled as strings of up to 9 characters length. For US addresses, these represent either a 3-digit abbreviated Zip code as provided by many sources for patient protection reasons, the full 5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons analytical methods should expect and utilize only the first 3 digits. For international addresses, different rules apply.
+Zip codes are handled as strings of up to 9 characters length. For US
+addresses, these represent either a 3-digit abbreviated Zip code as
+provided by many sources for patient protection reasons, the full
+5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons
+analytical methods should expect and utilize only the first 3 digits.
+For international addresses, different rules apply.
 </td>
 <td style="text-align:left;">
 varchar(9)
@@ -7992,7 +9188,8 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Put the verbatim value for the location here, as it shows up in the source.
+Put the verbatim value for the location here, as it shows up in the
+source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8069,7 +9266,9 @@ <h3 class="tabset tabset-pills">LOCATION</h3>
 <div id="location_history" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">LOCATION_HISTORY</h3>
 <p><strong>Table Description</strong></p>
-<p>The LOCATION HISTORY table stores relationships between Persons or Care Sites and geographic locations over time. <strong>This table is new to CDM v6.0</strong></p>
+<p>The LOCATION HISTORY table stores relationships between Persons or
+Care Sites and geographic locations over time. <strong>This table is new
+to CDM v6.0</strong></p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -8135,10 +9334,15 @@ <h3 class="tabset tabset-pills">LOCATION_HISTORY</h3>
 relationship_type_concept_id
 </td>
 <td style="text-align:left;">
-This is the relationship between the location and the entity (PERSON, PROVIDER, or CARE_SITE)
+This is the relationship between the location and the entity (PERSON,
+PROVIDER, or CARE_SITE)
 </td>
 <td style="text-align:left;">
-Concepts in this field must be in the Location class. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Location&amp;page=1&amp;pageSize=15&amp;query=&amp;boosts">Accepted Concepts</a>. If the DOMAIN_ID is CARE_SITE this should be 0 and when the domain is PROVIDER the value is <a href="https://athena.ohdsi.org/search-terms/terms/4121722">Office</a>.
+Concepts in this field must be in the Location class. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Location&amp;page=1&amp;pageSize=15&amp;query=&amp;boosts">Accepted
+Concepts</a>. If the DOMAIN_ID is CARE_SITE this should be 0 and when
+the domain is PROVIDER the value is <a
+href="https://athena.ohdsi.org/search-terms/terms/4121722">Office</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8165,7 +9369,8 @@ <h3 class="tabset tabset-pills">LOCATION_HISTORY</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The domain of the entity that is related to the location. Either PERSON, PROVIDER, or CARE_SITE.
+The domain of the entity that is related to the location. Either PERSON,
+PROVIDER, or CARE_SITE.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8191,7 +9396,8 @@ <h3 class="tabset tabset-pills">LOCATION_HISTORY</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The unique identifier for the entity. References either person_id, provider_id, or care_site_id, depending on domain_id.
+The unique identifier for the entity. References either person_id,
+provider_id, or care_site_id, depending on domain_id.
 </td>
 <td style="text-align:left;">
 bigint
@@ -8268,9 +9474,23 @@ <h3 class="tabset tabset-pills">LOCATION_HISTORY</h3>
 <div id="care_site" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <p><strong>Table Description</strong></p>
-<p>The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).</p>
+<p>The CARE_SITE table contains a list of uniquely identified
+institutional (physical or organizational) units where healthcare
+delivery is practiced (offices, wards, hospitals, clinics, etc.).</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Care site is a unique combination of location_id and place_of_service_source_value. Care site does not take into account the provider (human) information such a specialty. Many source data do not make a distinction between individual and institutional providers. The CARE_SITE table contains the institutional providers. If the source, instead of uniquely identifying individual Care Sites, only provides limited information such as Place of Service, generic or “pooled” Care Site records are listed in the CARE_SITE table. There can be hierarchical and business relationships between Care Sites. For example, wards can belong to clinics or departments, which can in turn belong to hospitals, which in turn can belong to hospital systems, which in turn can belong to HMOs.The relationships between Care Sites are defined in the FACT_RELATIONSHIP table.</p>
+<p>Care site is a unique combination of location_id and
+place_of_service_source_value. Care site does not take into account the
+provider (human) information such a specialty. Many source data do not
+make a distinction between individual and institutional providers. The
+CARE_SITE table contains the institutional providers. If the source,
+instead of uniquely identifying individual Care Sites, only provides
+limited information such as Place of Service, generic or “pooled” Care
+Site records are listed in the CARE_SITE table. There can be
+hierarchical and business relationships between Care Sites. For example,
+wards can belong to clinics or departments, which can in turn belong to
+hospitals, which in turn can belong to hospital systems, which in turn
+can belong to HMOs.The relationships between Care Sites are defined in
+the FACT_RELATIONSHIP table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -8311,7 +9531,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Assign an id to each unique combination of location_id and place_of_service_source_value.
+Assign an id to each unique combination of location_id and
+place_of_service_source_value.
 </td>
 <td style="text-align:left;">
 bigint
@@ -8361,10 +9582,19 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 place_of_service_concept_id
 </td>
 <td style="text-align:left;">
-This is a high-level way of characterizing a Care Site. Typically, however, Care Sites can provide care in multiple settings (inpatient, outpatient, etc.) and this granularity should be reflected in the visit.
+This is a high-level way of characterizing a Care Site. Typically,
+however, Care Sites can provide care in multiple settings (inpatient,
+outpatient, etc.) and this granularity should be reflected in the visit.
 </td>
 <td style="text-align:left;">
-Choose the concept in the visit domain that best represents the setting in which healthcare is provided in the Care Site. If most visits in a Care Site are Inpatient, then the place_of_service_concept_id should represent Inpatient. If information is present about a unique Care Site (e.g. Pharmacy) then a Care Site record should be created. If this information is not available then set to 0. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Choose the concept in the visit domain that best represents the setting
+in which healthcare is provided in the Care Site. If most visits in a
+Care Site are Inpatient, then the place_of_service_concept_id should
+represent Inpatient. If information is present about a unique Care Site
+(e.g. Pharmacy) then a Care Site record should be created. If this
+information is not available then set to 0. <a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=2&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8389,7 +9619,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 location_id
 </td>
 <td style="text-align:left;">
-The location_id from the LOCATION table representing the physical location of the care_site.
+The location_id from the LOCATION table representing the physical
+location of the care_site.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8416,7 +9647,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 care_site_source_value
 </td>
 <td style="text-align:left;">
-The identifier of the care_site as it appears in the source data. This could be an identifier separate from the name of the care_site.
+The identifier of the care_site as it appears in the source data. This
+could be an identifier separate from the name of the care_site.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8444,7 +9676,8 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-Put the place of service of the care_site as it appears in the source data.
+Put the place of service of the care_site as it appears in the source
+data.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8469,9 +9702,16 @@ <h3 class="tabset tabset-pills">CARE_SITE</h3>
 <div id="provider" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PROVIDER</h3>
 <p><strong>Table Description</strong></p>
-<p>The PROVIDER table contains a list of uniquely identified healthcare providers. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc.</p>
+<p>The PROVIDER table contains a list of uniquely identified healthcare
+providers. These are individuals providing hands-on healthcare to
+patients, such as physicians, nurses, midwives, physical therapists
+etc.</p>
 <p><strong>User Guide</strong></p>
-<p>Many sources do not make a distinction between individual and institutional providers. The PROVIDER table contains the individual providers. If the source, instead of uniquely identifying individual providers, only provides limited information such as specialty, generic or ‘pooled’ Provider records are listed in the PROVIDER table.</p>
+<p>Many sources do not make a distinction between individual and
+institutional providers. The PROVIDER table contains the individual
+providers. If the source, instead of uniquely identifying individual
+providers, only provides limited information such as specialty, generic
+or ‘pooled’ Provider records are listed in the PROVIDER table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -8510,10 +9750,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 provider_id
 </td>
 <td style="text-align:left;">
-It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently.
+It is assumed that every provider with a different unique identifier is
+in fact a different person and should be treated independently.
 </td>
 <td style="text-align:left;">
-This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number.
+This identifier can be the original id from the source data provided it
+is an integer, otherwise it can be an autogenerated number.
 </td>
 <td style="text-align:left;">
 bigint
@@ -8539,7 +9781,9 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-This field is not necessary as it is not necessary to have the actual identity of the Provider. Rather, the idea is to uniquely and anonymously identify providers of care across the database.
+This field is not necessary as it is not necessary to have the actual
+identity of the Provider. Rather, the idea is to uniquely and
+anonymously identify providers of care across the database.
 </td>
 <td style="text-align:left;">
 varchar(255)
@@ -8563,7 +9807,8 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 npi
 </td>
 <td style="text-align:left;">
-This is the National Provider Number issued to health care providers in the US by the Centers for Medicare and Medicaid Services (CMS).
+This is the National Provider Number issued to health care providers in
+the US by the Centers for Medicare and Medicaid Services (CMS).
 </td>
 <td style="text-align:left;">
 </td>
@@ -8589,7 +9834,8 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 dea
 </td>
 <td style="text-align:left;">
-This is the identifier issued by the DEA, a US federal agency, that allows a provider to write prescriptions for controlled substances.
+This is the identifier issued by the DEA, a US federal agency, that
+allows a provider to write prescriptions for controlled substances.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8615,10 +9861,20 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 specialty_concept_id
 </td>
 <td style="text-align:left;">
-This field either represents the most common specialty that occurs in the data or the most specific concept that represents all specialties listed, should the provider have more than one. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.
+This field either represents the most common specialty that occurs in
+the data or the most specific concept that represents all specialties
+listed, should the provider have more than one. This includes physician
+specialties such as internal medicine, emergency medicine, etc. and
+allied health professionals such as nurses, midwives, and pharmacists.
 </td>
 <td style="text-align:left;">
-If a Provider has more than one Specialty, there are two options: 1. Choose a concept_id which is a common ancestor to the multiple specialties, or, 2. Choose the specialty that occurs most often for the provider. Concepts in this field should be Standard with a domain of Provider. If not available, set to 0. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Provider&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If a Provider has more than one Specialty, there are two options: 1.
+Choose a concept_id which is a common ancestor to the multiple
+specialties, or, 2. Choose the specialty that occurs most often for the
+provider. Concepts in this field should be Standard with a domain of
+Provider. If not available, set to 0. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Provider&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8643,10 +9899,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 care_site_id
 </td>
 <td style="text-align:left;">
-This is the CARE_SITE_ID for the location that the provider primarily practices in.
+This is the CARE_SITE_ID for the location that the provider primarily
+practices in.
 </td>
 <td style="text-align:left;">
-If a Provider has more than one Care Site, the main or most often exerted CARE_SITE_ID should be recorded.
+If a Provider has more than one Care Site, the main or most often
+exerted CARE_SITE_ID should be recorded.
 </td>
 <td style="text-align:left;">
 bigint
@@ -8696,10 +9954,14 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 gender_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the recorded gender of the provider in the source data.
+This field represents the recorded gender of the provider in the source
+data.
 </td>
 <td style="text-align:left;">
-If given, put a concept from the gender domain representing the recorded gender of the provider. If not available, set to 0. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If given, put a concept from the gender domain representing the recorded
+gender of the provider. If not available, set to 0. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -8725,10 +9987,13 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 provider_source_value
 </td>
 <td style="text-align:left;">
-Use this field to link back to providers in the source data. This is typically used for error checking of ETL logic.
+Use this field to link back to providers in the source data. This is
+typically used for error checking of ETL logic.
 </td>
 <td style="text-align:left;">
-Some use cases require the ability to link back to providers in the source data. This field allows for the storing of the provider identifier as it appears in the source.
+Some use cases require the ability to link back to providers in the
+source data. This field allows for the storing of the provider
+identifier as it appears in the source.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8752,10 +10017,15 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 specialty_source_value
 </td>
 <td style="text-align:left;">
-This is the kind of provider or specialty as it appears in the source data. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.
+This is the kind of provider or specialty as it appears in the source
+data. This includes physician specialties such as internal medicine,
+emergency medicine, etc. and allied health professionals such as nurses,
+midwives, and pharmacists.
 </td>
 <td style="text-align:left;">
-Put the kind of provider as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.
+Put the kind of provider as it appears in the source data. This field is
+up to the discretion of the ETL-er as to whether this should be the
+coded value from the source or the text description of the lookup value.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8779,10 +10049,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 specialty_source_concept_id
 </td>
 <td style="text-align:left;">
-This is often zero as many sites use proprietary codes to store physician speciality.
+This is often zero as many sites use proprietary codes to store
+physician speciality.
 </td>
 <td style="text-align:left;">
-If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here. If not available, set to 0.
+If the source data codes provider specialty in an OMOP supported
+vocabulary store the concept_id here. If not available, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -8810,7 +10082,9 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 This is provider’s gender as it appears in the source data.
 </td>
 <td style="text-align:left;">
-Put the provider’s gender as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.
+Put the provider’s gender as it appears in the source data. This field
+is up to the discretion of the ETL-er as to whether this should be the
+coded value from the source or the text description of the lookup value.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -8834,10 +10108,12 @@ <h3 class="tabset tabset-pills">PROVIDER</h3>
 gender_source_concept_id
 </td>
 <td style="text-align:left;">
-This is often zero as many sites use proprietary codes to store provider gender.
+This is often zero as many sites use proprietary codes to store provider
+gender.
 </td>
 <td style="text-align:left;">
-If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here. If not available, set to 0.
+If the source data codes provider gender in an OMOP supported vocabulary
+store the concept_id here. If not available, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -8866,9 +10142,25 @@ <h2><strong>Health Economics Data Tables</strong></h2>
 <div id="payer_plan_period" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <p><strong>Table Description</strong></p>
-<p>The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.</p>
+<p>The PAYER_PLAN_PERIOD table captures details of the period of time
+that a Person is continuously enrolled under a specific health Plan
+benefit structure from a given Payer. Each Person receiving healthcare
+is typically covered by a health benefit plan, which pays for (fully or
+partially), or directly provides, the care. These benefit plans are
+provided by payers, such as health insurances or state or government
+agencies. In each plan the details of the health benefits are defined
+for the Person or her family, and the health benefit Plan might change
+over time typically with increasing utilization (reaching certain cost
+thresholds such as deductibles), plan availability and purchasing
+choices of the Person. The unique combinations of Payer organizations,
+health benefit Plans and time periods in which they are valid for a
+Person are recorded in this table.</p>
 <p><strong>User Guide</strong></p>
-<p>A Person can have multiple, overlapping, Payer_Plan_Periods in this table. For example, medical and drug coverage in the US can be represented by two Payer_Plan_Periods. The details of the benefit structure of the Plan is rarely known, the idea is just to identify that the Plans are different.</p>
+<p>A Person can have multiple, overlapping, Payer_Plan_Periods in this
+table. For example, medical and drug coverage in the US can be
+represented by two Payer_Plan_Periods. The details of the benefit
+structure of the Plan is rarely known, the idea is just to identify that
+the Plans are different.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -8907,7 +10199,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 payer_plan_period_id
 </td>
 <td style="text-align:left;">
-A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time.
+A unique identifier for each unique combination of a Person, Payer,
+Plan, and Period of time.
 </td>
 <td style="text-align:left;">
 </td>
@@ -8935,7 +10228,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 The Person covered by the Plan.
 </td>
 <td style="text-align:left;">
-A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records
+A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD
+records
 </td>
 <td style="text-align:left;">
 bigint
@@ -8963,7 +10257,11 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 The Person who is the primary subscriber/contract owner for Plan.
 </td>
 <td style="text-align:left;">
-This may or may not be the same as the PERSON_ID. For example, if a mother has her son on her plan and the PAYER_PLAN_PERIOD record is the for son, the sons’s PERSON_ID would go in PAYER_PLAN_PERIOD.PERSON_ID and the mother’s PERSON_ID would go in PAYER_PLAN_PERIOD.CONTRACT_PERSON_ID.
+This may or may not be the same as the PERSON_ID. For example, if a
+mother has her son on her plan and the PAYER_PLAN_PERIOD record is the
+for son, the sons’s PERSON_ID would go in PAYER_PLAN_PERIOD.PERSON_ID
+and the mother’s PERSON_ID would go in
+PAYER_PLAN_PERIOD.CONTRACT_PERSON_ID.
 </td>
 <td style="text-align:left;">
 bigint
@@ -9040,10 +10338,17 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 payer_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the organization who reimburses the provider which administers care to the Person.
+This field represents the organization who reimburses the provider which
+administers care to the Person.
 </td>
 <td style="text-align:left;">
-Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. If not available, set to 0. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the Payer directly to a standard CONCEPT_ID. If one does not exists
+please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. The point is to stratify on
+this information and identify if Persons have the same payer, though the
+name of the Payer is not necessary. If not available, set to 0. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -9096,7 +10401,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here. If not available, set to 0.
+If the source data codes the Payer in an OMOP supported vocabulary store
+the concept_id here. If not available, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -9121,10 +10427,18 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 plan_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the specific health benefit Plan the Person is enrolled in.
+This field represents the specific health benefit Plan the Person is
+enrolled in.
 </td>
 <td style="text-align:left;">
-Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. If not available, set to 0. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Plan&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the Plan directly to a standard CONCEPT_ID. If one does not exists
+please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. The point is to stratify on
+this information and identify if Persons have the same health benefit
+Plan though the name of the Plan is not necessary. If not available, set
+to 0. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Plan&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -9149,7 +10463,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 plan_source_value
 </td>
 <td style="text-align:left;">
-This is the health benefit Plan of the Person as it appears in the source data.
+This is the health benefit Plan of the Person as it appears in the
+source data.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9177,7 +10492,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here. If not available, set to 0.
+If the source data codes the Plan in an OMOP supported vocabulary store
+the concept_id here. If not available, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -9202,10 +10518,22 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 contract_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the relationship between the PERSON_ID and CONTRACT_PERSON_ID. It should be read as PERSON_ID is the <em>CONTRACT_CONCEPT_ID</em> of the CONTRACT_PERSON_ID. So if CONTRACT_CONCEPT_ID represents the relationship ‘Stepdaughter’ then the Person for whom PAYER_PLAN_PERIOD record was recorded is the stepdaughter of the CONTRACT_PERSON_ID.
+This field represents the relationship between the PERSON_ID and
+CONTRACT_PERSON_ID. It should be read as PERSON_ID is the
+<em>CONTRACT_CONCEPT_ID</em> of the CONTRACT_PERSON_ID. So if
+CONTRACT_CONCEPT_ID represents the relationship ‘Stepdaughter’ then the
+Person for whom PAYER_PLAN_PERIOD record was recorded is the
+stepdaughter of the CONTRACT_PERSON_ID.
 </td>
 <td style="text-align:left;">
-If available, use this field to represent the relationship between the PERSON_ID and the CONTRACT_PERSON_ID. If the Person for whom the PAYER_PLAN_PERIOD record was recorded is the stepdaughter of the CONTRACT_PERSON_ID then CONTRACT_CONCEPT_ID would be <a href="https://athena.ohdsi.org/search-terms/terms/4330864">4330864</a>. If not available, set to 0. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Relationship&amp;page=12&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+If available, use this field to represent the relationship between the
+PERSON_ID and the CONTRACT_PERSON_ID. If the Person for whom the
+PAYER_PLAN_PERIOD record was recorded is the stepdaughter of the
+CONTRACT_PERSON_ID then CONTRACT_CONCEPT_ID would be <a
+href="https://athena.ohdsi.org/search-terms/terms/4330864">4330864</a>.
+If not available, set to 0. <a
+href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Relationship&amp;page=12&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -9230,7 +10558,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 contract_source_value
 </td>
 <td style="text-align:left;">
-This is the relationship of the PERSON_ID to CONTRACT_PERSON_ID as it appears in the source data.
+This is the relationship of the PERSON_ID to CONTRACT_PERSON_ID as it
+appears in the source data.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9258,7 +10587,9 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the relationship between the PERSON_ID and CONTRACT_PERSON_ID in an OMOP supported vocabulary store the concept_id here. If not available, set to 0.
+If the source data codes the relationship between the PERSON_ID and
+CONTRACT_PERSON_ID in an OMOP supported vocabulary store the concept_id
+here. If not available, set to 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -9283,10 +10614,18 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 sponsor_concept_id
 </td>
 <td style="text-align:left;">
-This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan.
+This field represents the sponsor of the Plan who finances the Plan.
+This includes self-insured, small group health plan and large group
+health plan.
 </td>
 <td style="text-align:left;">
-Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. If not available, set to 0. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the sponsor directly to a standard CONCEPT_ID. If one does not
+exists please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. The point is to stratify on
+this information and identify if Persons have the same sponsor though
+the name of the sponsor is not necessary. If not available, set to 0. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -9339,7 +10678,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the sponsor in an OMOP supported vocabulary
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -9364,10 +10704,12 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 family_source_value
 </td>
 <td style="text-align:left;">
-The common identifier for all people (often a family) that covered by the same policy.
+The common identifier for all people (often a family) that covered by
+the same policy.
 </td>
 <td style="text-align:left;">
-Often these are the common digits of the enrollment id of the policy members.
+Often these are the common digits of the enrollment id of the policy
+members.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -9394,7 +10736,11 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 This field represents the reason the Person left the Plan, if known.
 </td>
 <td style="text-align:left;">
-Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. <a href="http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
+Map the stop reason directly to a standard CONCEPT_ID. If one does not
+exists please contact the vocabulary team. There is no global controlled
+vocabulary available for this information. <a
+href="http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+Concepts</a>.
 </td>
 <td style="text-align:left;">
 integer
@@ -9447,7 +10793,8 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here.
+If the source data codes the stop reason in an OMOP supported vocabulary
+store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -9473,12 +10820,36 @@ <h3 class="tabset tabset-pills">PAYER_PLAN_PERIOD</h3>
 <div id="cost" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">COST</h3>
 <p><strong>Table Description</strong></p>
-<p>The COST table captures records containing the cost of any medical event recorded in one of the OMOP clinical event tables such as DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL, DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT.</p>
-<p>Each record in the cost table account for the amount of money transacted for the clinical event. So, the COST table may be used to represent both receivables (charges) and payments (paid), each transaction type represented by its COST_CONCEPT_ID. The COST_TYPE_CONCEPT_ID field will use concepts in the Standardized Vocabularies to designate the source (provenance) of the cost data. A reference to the health plan information in the PAYER_PLAN_PERIOD table is stored in the record for information used for the adjudication system to determine the persons benefit for the clinical event.</p>
+<p>The COST table captures records containing the cost of any medical
+event recorded in one of the OMOP clinical event tables such as
+DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL,
+DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT.</p>
+<p>Each record in the cost table account for the amount of money
+transacted for the clinical event. So, the COST table may be used to
+represent both receivables (charges) and payments (paid), each
+transaction type represented by its COST_CONCEPT_ID. The
+COST_TYPE_CONCEPT_ID field will use concepts in the Standardized
+Vocabularies to designate the source (provenance) of the cost data. A
+reference to the health plan information in the PAYER_PLAN_PERIOD table
+is stored in the record for information used for the adjudication system
+to determine the persons benefit for the clinical event.</p>
 <p><strong>User Guide</strong></p>
-<p>When dealing with summary costs, the cost of the goods or services the provider provides is often not known directly, but derived from the hospital charges multiplied by an average cost-to-charge ratio.</p>
+<p>When dealing with summary costs, the cost of the goods or services
+the provider provides is often not known directly, but derived from the
+hospital charges multiplied by an average cost-to-charge ratio.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. Therefore, it is possible for one procedure to have multiple cost records for each payer, but typically it contains one or no record per entity. Payer reimbursement cost records will be identified by using the PAYER_PLAN_ID field. Drug costs are composed of ingredient cost (the amount charged by the wholesale distributor or manufacturer), the dispensing fee (the amount charged by the pharmacy and the sales tax).</p>
+<p>One cost record is generated for each response by a payer. In a
+claims databases, the payment and payment terms reported by the payer
+for the goods or services billed will generate one cost record. If the
+source data has payment information for more than one payer
+(i.e. primary insurance and secondary insurance payment for one entity),
+then a cost record is created for each reporting payer. Therefore, it is
+possible for one procedure to have multiple cost records for each payer,
+but typically it contains one or no record per entity. Payer
+reimbursement cost records will be identified by using the PAYER_PLAN_ID
+field. Drug costs are composed of ingredient cost (the amount charged by
+the wholesale distributor or manufacturer), the dispensing fee (the
+amount charged by the pharmacy and the sales tax).</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -9568,7 +10939,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 cost_event_id
 </td>
 <td style="text-align:left;">
-If the Cost record is related to another record in the database, this field is the primary key of the linked record.
+If the Cost record is related to another record in the database, this
+field is the primary key of the linked record.
 </td>
 <td style="text-align:left;">
 Put the primary key of the linked record, if applicable, here.
@@ -9595,10 +10967,13 @@ <h3 class="tabset tabset-pills">COST</h3>
 cost_event_field_concept_id
 </td>
 <td style="text-align:left;">
-If the Cost record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from.
+If the Cost record is related to another record in the database, this
+field is the CONCEPT_ID that identifies which table the primary key of
+the linked record came from.
 </td>
 <td style="text-align:left;">
-Put the CONCEPT_ID that identifies which table and field the COST_EVENT_ID came from.
+Put the CONCEPT_ID that identifies which table and field the
+COST_EVENT_ID came from.
 </td>
 <td style="text-align:left;">
 integer
@@ -9623,7 +10998,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 cost_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key that refers to a Standard Cost Concept identifier in the Standardized Vocabularies belonging to the ‘Cost’ vocabulary.
+A foreign key that refers to a Standard Cost Concept identifier in the
+Standardized Vocabularies belonging to the ‘Cost’ vocabulary.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9650,7 +11026,9 @@ <h3 class="tabset tabset-pills">COST</h3>
 cost_type_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key identifier to a concept in the CONCEPT table for the provenance or the source of the COST data and belonging to the ‘Type Concept’ vocabulary
+A foreign key identifier to a concept in the CONCEPT table for the
+provenance or the source of the COST data and belonging to the ‘Type
+Concept’ vocabulary
 </td>
 <td style="text-align:left;">
 </td>
@@ -9678,7 +11056,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 cost_source_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key to a Cost Concept that refers to the code used in the source.
+A foreign key to a Cost Concept that refers to the code used in the
+source.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9731,7 +11110,9 @@ <h3 class="tabset tabset-pills">COST</h3>
 currency_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key identifier to the concept representing the 3-letter code used to delineate international currencies, such as USD for US Dollar. These belong to the ‘Currency’ vocabulary
+A foreign key identifier to the concept representing the 3-letter code
+used to delineate international currencies, such as USD for US Dollar.
+These belong to the ‘Currency’ vocabulary
 </td>
 <td style="text-align:left;">
 </td>
@@ -9784,7 +11165,9 @@ <h3 class="tabset tabset-pills">COST</h3>
 incurred_date
 </td>
 <td style="text-align:left;">
-The first date of service of the clinical event corresponding to the cost as in table capturing the information (e.g. date of visit, date of procedure, date of condition, date of drug etc).
+The first date of service of the clinical event corresponding to the
+cost as in table capturing the information (e.g. date of visit, date of
+procedure, date of condition, date of drug etc).
 </td>
 <td style="text-align:left;">
 </td>
@@ -9862,7 +11245,9 @@ <h3 class="tabset tabset-pills">COST</h3>
 revenue_code_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for Revenue codes belonging to the ‘Revenue Code’ vocabulary.
+A foreign key referring to a Standard Concept ID in the Standardized
+Vocabularies for Revenue codes belonging to the ‘Revenue Code’
+vocabulary.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9889,7 +11274,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 drg_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for DRG codes belonging to the ‘DRG’ vocabulary.
+A foreign key referring to a Standard Concept ID in the Standardized
+Vocabularies for DRG codes belonging to the ‘DRG’ vocabulary.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9916,7 +11302,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 revenue_code_source_value
 </td>
 <td style="text-align:left;">
-The source value for the Revenue code as it appears in the source data, stored here for reference.
+The source value for the Revenue code as it appears in the source data,
+stored here for reference.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9942,7 +11329,8 @@ <h3 class="tabset tabset-pills">COST</h3>
 drg_source_value
 </td>
 <td style="text-align:left;">
-The source value for the 3-digit DRG source code as it appears in the source data, stored here for reference.
+The source value for the 3-digit DRG source code as it appears in the
+source data, stored here for reference.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9968,7 +11356,9 @@ <h3 class="tabset tabset-pills">COST</h3>
 payer_plan_period_id
 </td>
 <td style="text-align:left;">
-A foreign key to the PAYER_PLAN_PERIOD table, where the details of the Payer, Plan and Family are stored. Record the payer_plan_id that relates to the payer who contributed to the paid_by_payer field.
+A foreign key to the PAYER_PLAN_PERIOD table, where the details of the
+Payer, Plan and Family are stored. Record the payer_plan_id that relates
+to the payer who contributed to the paid_by_payer field.
 </td>
 <td style="text-align:left;">
 </td>
@@ -9998,9 +11388,15 @@ <h2><strong>Standardized Derived Elements</strong></h2>
 <div id="drug_era" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <p><strong>Table Description</strong></p>
-<p>A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras.</p>
+<p>A Drug Era is defined as a span of time when the Person is assumed to
+be exposed to a particular active ingredient. A Drug Era is not the same
+as a Drug Exposure: Exposures are individual records corresponding to
+the source when Drug was delivered to the Person, while successive
+periods of Drug Exposures are combined under certain rules to produce
+continuous Drug Eras.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>The SQL script for generating DRUG_ERA records can be found <a href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#drug_eras">here</a>.</p>
+<p>The SQL script for generating DRUG_ERA records can be found <a
+href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#drug_eras">here</a>.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10120,7 +11516,8 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure.
+The Drug Era Start Date is the start date of the first Drug Exposure for
+a given ingredient, with at least 31 days since the previous exposure.
 </td>
 <td style="text-align:left;">
 datetime
@@ -10146,7 +11543,19 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules: For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information. For Procedure Drugs, usually the drug is administered on a single date (i.e., the administration date). A standard Persistence Window of 30 days (gap, slack) is permitted between two subsequent such extrapolated DRUG_EXPOSURE records to be considered to be merged into a single Drug Era.
+The Drug Era End Date is the end date of the last Drug Exposure. The End
+Date of each Drug Exposure is either taken from the field
+drug_exposure_end_date or, as it is typically not available, inferred
+using the following rules: For pharmacy prescription data, the date when
+the drug was dispensed plus the number of days of supply are used to
+extrapolate the End Date for the Drug Exposure. Depending on the
+country-specific healthcare system, this supply information is either
+explicitly provided in the day_supply field or inferred from package
+size or similar information. For Procedure Drugs, usually the drug is
+administered on a single date (i.e., the administration date). A
+standard Persistence Window of 30 days (gap, slack) is permitted between
+two subsequent such extrapolated DRUG_EXPOSURE records to be considered
+to be merged into a single Drug Era.
 </td>
 <td style="text-align:left;">
 datetime
@@ -10197,7 +11606,16 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The Gap Days determine how many total drug-free days are observed between all Drug Exposure events that contribute to a DRUG_ERA record. It is assumed that the drugs are “not stockpiled” by the patient, i.e. that if a new drug prescription or refill is observed (a new DRUG_EXPOSURE record is written), the remaining supply from the previous events is abandoned. The difference between Persistence Window and Gap Days is that the former is the maximum drug-free time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual drug-free days for the given Drug Era under the above assumption of non-stockpiling.
+The Gap Days determine how many total drug-free days are observed
+between all Drug Exposure events that contribute to a DRUG_ERA record.
+It is assumed that the drugs are “not stockpiled” by the patient,
+i.e. that if a new drug prescription or refill is observed (a new
+DRUG_EXPOSURE record is written), the remaining supply from the previous
+events is abandoned. The difference between Persistence Window and Gap
+Days is that the former is the maximum drug-free time allowed between
+two subsequent DRUG_EXPOSURE records, while the latter is the sum of
+actual drug-free days for the given Drug Era under the above assumption
+of non-stockpiling.
 </td>
 <td style="text-align:left;">
 integer
@@ -10222,9 +11640,15 @@ <h3 class="tabset tabset-pills">DRUG_ERA</h3>
 <div id="dose_era" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 <p><strong>Table Description</strong></p>
-<p>A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.</p>
+<p>A Dose Era is defined as a span of time when the Person is assumed to
+be exposed to a constant dose of a specific active ingredient.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Dose Eras will be derived from records in the DRUG_EXPOSURE table and the Dose information from the DRUG_STRENGTH table using a standardized algorithm. Dose Form information is not taken into account. So, if the patient changes between different formulations, or different manufacturers with the same formulation, the Dose Era is still spanning the entire time of exposure to the Ingredient.</p>
+<p>Dose Eras will be derived from records in the DRUG_EXPOSURE table and
+the Dose information from the DRUG_STRENGTH table using a standardized
+algorithm. Dose Form information is not taken into account. So, if the
+patient changes between different formulations, or different
+manufacturers with the same formulation, the Dose Era is still spanning
+the entire time of exposure to the Ingredient.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10396,7 +11820,8 @@ <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 dose_era_start_datetime
 </td>
 <td style="text-align:left;">
-The date the Person started on the specific dosage, with at least 31 days since any prior exposure.
+The date the Person started on the specific dosage, with at least 31
+days since any prior exposure.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10424,7 +11849,9 @@ <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 <td style="text-align:left;">
 </td>
 <td style="text-align:left;">
-The date the Person was no longer exposed to the dosage of the specific drug ingredient. An era is ended if there are 31 days or more between dosage records.
+The date the Person was no longer exposed to the dosage of the specific
+drug ingredient. An era is ended if there are 31 days or more between
+dosage records.
 </td>
 <td style="text-align:left;">
 datetime
@@ -10449,13 +11876,39 @@ <h3 class="tabset tabset-pills">DOSE_ERA</h3>
 <div id="condition_era" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 <p><strong>Table Description</strong></p>
-<p>A Condition Era is defined as a span of time when the Person is assumed to have a given condition. Similar to Drug Eras, Condition Eras are chronological periods of Condition Occurrence. Combining individual Condition Occurrences into a single Condition Era serves two purposes:</p>
+<p>A Condition Era is defined as a span of time when the Person is
+assumed to have a given condition. Similar to Drug Eras, Condition Eras
+are chronological periods of Condition Occurrence. Combining individual
+Condition Occurrences into a single Condition Era serves two
+purposes:</p>
 <ul>
-<li>It allows aggregation of chronic conditions that require frequent ongoing care, instead of treating each Condition Occurrence as an independent event.</li>
-<li>It allows aggregation of multiple, closely timed doctor visits for the same Condition to avoid double-counting the Condition Occurrences. For example, consider a Person who visits her Primary Care Physician (PCP) and who is referred to a specialist. At a later time, the Person visits the specialist, who confirms the PCP’s original diagnosis and provides the appropriate treatment to resolve the condition. These two independent doctor visits should be aggregated into one Condition Era.</li>
+<li>It allows aggregation of chronic conditions that require frequent
+ongoing care, instead of treating each Condition Occurrence as an
+independent event.</li>
+<li>It allows aggregation of multiple, closely timed doctor visits for
+the same Condition to avoid double-counting the Condition Occurrences.
+For example, consider a Person who visits her Primary Care Physician
+(PCP) and who is referred to a specialist. At a later time, the Person
+visits the specialist, who confirms the PCP’s original diagnosis and
+provides the appropriate treatment to resolve the condition. These two
+independent doctor visits should be aggregated into one Condition
+Era.</li>
 </ul>
 <p><strong>ETL Conventions</strong></p>
-<p>Each Condition Era corresponds to one or many Condition Occurrence records that form a continuous interval. The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers. The SQl Script for generating CONDITION_ERA records can be found <a href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#condition_eras">here</a> The Condition Era Start Date is the start date of the first Condition Occurrence. The Condition Era End Date is the end date of the last Condition Occurrence. Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurrence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date.</p>
+<p>Each Condition Era corresponds to one or many Condition Occurrence
+records that form a continuous interval. The condition_concept_id field
+contains Concepts that are identical to those of the
+CONDITION_OCCURRENCE table records that make up the Condition Era. In
+contrast to Drug Eras, Condition Eras are not aggregated to contain
+Conditions of different hierarchical layers. The SQl Script for
+generating CONDITION_ERA records can be found <a
+href="https://ohdsi.github.io/CommonDataModel/sqlScripts.html#condition_eras">here</a>
+The Condition Era Start Date is the start date of the first Condition
+Occurrence. The Condition Era End Date is the end date of the last
+Condition Occurrence. Condition Eras are built with a Persistence Window
+of 30 days, meaning, if no occurrence of the same condition_concept_id
+happens within 30 days of any one occurrence, it will be considered the
+condition_era_end_date.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10573,7 +12026,10 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 condition_era_start_datetime
 </td>
 <td style="text-align:left;">
-The start date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the start date of the very first chronologically recorded instance of the condition with at least 31 days since any prior record of the same Condition.
+The start date for the Condition Era constructed from the individual
+instances of Condition Occurrences. It is the start date of the very
+first chronologically recorded instance of the condition with at least
+31 days since any prior record of the same Condition.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10599,7 +12055,9 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 condition_era_end_datetime
 </td>
 <td style="text-align:left;">
-The end date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the end date of the final continuously recorded instance of the Condition.
+The end date for the Condition Era constructed from the individual
+instances of Condition Occurrences. It is the end date of the final
+continuously recorded instance of the Condition.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10625,7 +12083,8 @@ <h3 class="tabset tabset-pills">CONDITION_ERA</h3>
 condition_occurrence_count
 </td>
 <td style="text-align:left;">
-The number of individual Condition Occurrences used to construct the condition era.
+The number of individual Condition Occurrences used to construct the
+condition era.
 </td>
 <td style="text-align:left;">
 </td>
@@ -10655,7 +12114,8 @@ <h2><strong>Metadata Tables</strong></h2>
 <div id="metadata" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">METADATA</h3>
 <p><strong>Table Description</strong></p>
-<p>The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.</p>
+<p>The METADATA table contains metadata information about a dataset that
+has been transformed to the OMOP Common Data Model.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -10873,7 +12333,9 @@ <h3 class="tabset tabset-pills">METADATA</h3>
 <div id="cdm_source" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CDM_SOURCE</h3>
 <p><strong>Table Description</strong></p>
-<p>The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.</p>
+<p>The CDM_SOURCE table contains detail about the source database and
+the process used to transform the data into the OMOP Common Data
+Model.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11173,9 +12635,26 @@ <h2><strong>Vocabulary Tables</strong></h2>
 <div id="concept" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT</h3>
 <p><strong>Table Description</strong></p>
-<p>The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and within standardized analytics. Each Standard Concept belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.</p>
-<p>Concepts can represent broad categories (like ‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’) or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.).</p>
-<p>Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom Concepts defined to cover various aspects of observational data analysis.</p>
+<p>The Standardized Vocabularies contains records, or Concepts, that
+uniquely identify each fundamental unit of meaning used to express
+clinical information in all domain tables of the CDM. Concepts are
+derived from vocabularies, which represent clinical information across a
+domain (e.g. conditions, drugs, procedures) through the use of codes and
+associated descriptions. Some Concepts are designated Standard Concepts,
+meaning these Concepts can be used as normative expressions of a
+clinical entity within the OMOP Common Data Model and within
+standardized analytics. Each Standard Concept belongs to one domain,
+which defines the location where the Concept would be expected to occur
+within data tables of the CDM.</p>
+<p>Concepts can represent broad categories (like ‘Cardiovascular
+disease’), detailed clinical elements (‘Myocardial infarction of the
+anterolateral wall’) or modifying characteristics and attributes that
+define Concepts at various levels of detail (severity of a disease,
+associated morphology, etc.).</p>
+<p>Records in the Standardized Vocabularies tables are derived from
+national or international vocabularies such as SNOMED-CT, RxNorm, and
+LOINC, or custom Concepts defined to cover various aspects of
+observational data analysis.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11266,7 +12745,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 domain_id
 </td>
 <td style="text-align:left;">
-A foreign key to the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#domain">DOMAIN</a> table the Concept belongs to.
+A foreign key to the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#domain">DOMAIN</a>
+table the Concept belongs to.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11293,7 +12774,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 vocabulary_id
 </td>
 <td style="text-align:left;">
-A foreign key to the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#vocabulary">VOCABULARY</a> table indicating from which source the Concept has been adapted.
+A foreign key to the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#vocabulary">VOCABULARY</a>
+table indicating from which source the Concept has been adapted.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11320,7 +12803,8 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 concept_class_id
 </td>
 <td style="text-align:left;">
-The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc.
+The attribute or concept class of the Concept. Examples are ‘Clinical
+Drug’, ‘Ingredient’, ‘Clinical Finding’ etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11347,7 +12831,10 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 standard_concept
 </td>
 <td style="text-align:left;">
-This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL.
+This flag determines where a Concept is a Standard Concept, i.e. is used
+in the data, a Classification Concept, or a non-standard Source Concept.
+The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification
+Concept), otherwise the content is NULL.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11373,7 +12860,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 concept_code
 </td>
 <td style="text-align:left;">
-The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies.
+The concept code represents the identifier of the Concept in the source
+vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that
+concept codes are not unique across vocabularies.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11399,7 +12888,8 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 valid_start_date
 </td>
 <td style="text-align:left;">
-The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning, the Concept has no (known) date of inception.
+The date when the Concept was first recorded. The default value is
+1-Jan-1970, meaning, the Concept has no (known) date of inception.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11425,7 +12915,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 valid_end_date
 </td>
 <td style="text-align:left;">
-The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning, the Concept is valid until it becomes deprecated.
+The date when the Concept became invalid because it was deleted or
+superseded (updated) by a new concept. The default value is 31-Dec-2099,
+meaning, the Concept is valid until it becomes deprecated.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11451,7 +12943,9 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-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.
+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.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11478,7 +12972,11 @@ <h3 class="tabset tabset-pills">CONCEPT</h3>
 <div id="vocabulary" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">VOCABULARY</h3>
 <p><strong>Table Description</strong></p>
-<p>The VOCABULARY table includes a list of the Vocabularies collected from various sources or created de novo by the OMOP community. This reference table is populated with a single record for each Vocabulary source and includes a descriptive name and other associated attributes for the Vocabulary.</p>
+<p>The VOCABULARY table includes a list of the Vocabularies collected
+from various sources or created de novo by the OMOP community. This
+reference table is populated with a single record for each Vocabulary
+source and includes a descriptive name and other associated attributes
+for the Vocabulary.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11543,7 +13041,9 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 vocabulary_name
 </td>
 <td style="text-align:left;">
-The name describing the vocabulary, for example International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS) etc.
+The name describing the vocabulary, for example International
+Classification of Diseases, Ninth Revision, Clinical Modification,
+Volume 1 and 2 (NCHS) etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11569,7 +13069,8 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 vocabulary_reference
 </td>
 <td style="text-align:left;">
-External reference to documentation or available download of the about the vocabulary.
+External reference to documentation or available download of the about
+the vocabulary.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11621,7 +13122,8 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 vocabulary_concept_id
 </td>
 <td style="text-align:left;">
-A Concept that represents the Vocabulary the VOCABULARY record belongs to.
+A Concept that represents the Vocabulary the VOCABULARY record belongs
+to.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11649,7 +13151,14 @@ <h3 class="tabset tabset-pills">VOCABULARY</h3>
 <div id="domain" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DOMAIN</h3>
 <p><strong>Table Description</strong></p>
-<p>The DOMAIN table includes a list of OMOP-defined Domains the Concepts of the Standardized Vocabularies can belong to. A Domain defines the set of allowable Concepts for the standardized fields in the CDM tables. For example, the “Condition” Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.</p>
+<p>The DOMAIN table includes a list of OMOP-defined Domains the Concepts
+of the Standardized Vocabularies can belong to. A Domain defines the set
+of allowable Concepts for the standardized fields in the CDM tables. For
+example, the “Condition” Domain contains Concepts that describe a
+condition of a patient, and these Concepts can only be stored in the
+condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA
+tables. This reference table is populated with a single record for each
+Domain and includes a descriptive name for the Domain.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11714,7 +13223,8 @@ <h3 class="tabset tabset-pills">DOMAIN</h3>
 domain_name
 </td>
 <td style="text-align:left;">
-The name describing the Domain, e.g. Condition, Procedure, Measurement etc.
+The name describing the Domain, e.g. Condition, Procedure, Measurement
+etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11768,7 +13278,10 @@ <h3 class="tabset tabset-pills">DOMAIN</h3>
 <div id="concept_class" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_CLASS</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_CLASS table is a reference table, which includes a list of the classifications used to differentiate Concepts within a given Vocabulary. This reference table is populated with a single record for each Concept Class.</p>
+<p>The CONCEPT_CLASS table is a reference table, which includes a list
+of the classifications used to differentiate Concepts within a given
+Vocabulary. This reference table is populated with a single record for
+each Concept Class.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11833,7 +13346,8 @@ <h3 class="tabset tabset-pills">CONCEPT_CLASS</h3>
 concept_class_name
 </td>
 <td style="text-align:left;">
-The name describing the Concept Class, e.g. Clinical Finding, Ingredient, etc.
+The name describing the Concept Class, e.g. Clinical Finding,
+Ingredient, etc.
 </td>
 <td style="text-align:left;">
 </td>
@@ -11884,10 +13398,14 @@ <h3 class="tabset tabset-pills">CONCEPT_CLASS</h3>
 </tbody>
 </table>
 </div>
-<div id="concept_relationship" class="section level3 tabset tabset-pills">
+<div id="concept_relationship"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the RELATIONSHIP table.</p>
+<p>The CONCEPT_RELATIONSHIP table contains records that define direct
+relationships between any two Concepts and the nature or type of the
+relationship. Each type of a relationship is defined in the RELATIONSHIP
+table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -11978,7 +13496,10 @@ <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 relationship_id
 </td>
 <td style="text-align:left;">
-The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the <a href="https://ohdsi.github.io/CommonDataModel/dataModelConventions.html#concept_relationships">Vocabulary Conventions</a>. for more information.
+The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the
+<a
+href="https://ohdsi.github.io/CommonDataModel/dataModelConventions.html#concept_relationships">Vocabulary
+Conventions</a>. for more information.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12057,7 +13578,8 @@ <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-Reason the relationship was invalidated. Possible values are ‘D’ (deleted), ‘U’ (updated) or NULL.
+Reason the relationship was invalidated. Possible values are ‘D’
+(deleted), ‘U’ (updated) or NULL.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12084,7 +13606,9 @@ <h3 class="tabset tabset-pills">CONCEPT_RELATIONSHIP</h3>
 <div id="relationship" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 <p><strong>Table Description</strong></p>
-<p>The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.</p>
+<p>The RELATIONSHIP table provides a reference list of all types of
+relationships that can be used to associate any two concepts in the
+CONCEPT_RELATIONSHP table.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12275,7 +13799,8 @@ <h3 class="tabset tabset-pills">RELATIONSHIP</h3>
 <div id="concept_synonym" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_SYNONYM</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.</p>
+<p>The CONCEPT_SYNONYM table is used to store alternate names and
+descriptions for Concepts.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12392,8 +13917,19 @@ <h3 class="tabset tabset-pills">CONCEPT_SYNONYM</h3>
 <div id="concept_ancestor" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 <p><strong>Table Description</strong></p>
-<p>The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.</p>
-<p>This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.</p>
+<p>The CONCEPT_ANCESTOR table is designed to simplify observational
+analysis by providing the complete hierarchical relationships between
+Concepts. Only direct parent-child relationships between Concepts are
+stored in the CONCEPT_RELATIONSHIP table. To determine higher level
+ancestry connections, all individual direct relationships would have to
+be navigated at analysis time. The CONCEPT_ANCESTOR table includes
+records for all parent-child relationships, as well as
+grandparent-grandchild relationships and those of any other level of
+lineage. Using the CONCEPT_ANCESTOR table allows for querying for all
+descendants of a hierarchical concept. For example, drug ingredients and
+drug products are all descendants of a drug class ancestor.</p>
+<p>This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP
+and RELATIONSHIP tables.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12432,7 +13968,8 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 ancestor_concept_id
 </td>
 <td style="text-align:left;">
-The Concept Id for the higher-level concept that forms the ancestor in the relationship.
+The Concept Id for the higher-level concept that forms the ancestor in
+the relationship.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12459,7 +13996,8 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 descendant_concept_id
 </td>
 <td style="text-align:left;">
-The Concept Id for the lower-level concept that forms the descendant in the relationship.
+The Concept Id for the lower-level concept that forms the descendant in
+the relationship.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12486,7 +14024,9 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 min_levels_of_separation
 </td>
 <td style="text-align:left;">
-The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.
+The minimum separation in number of levels of hierarchy between ancestor
+and descendant concepts. This is an attribute that is used to simplify
+hierarchic analysis.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12512,7 +14052,9 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 max_levels_of_separation
 </td>
 <td style="text-align:left;">
-The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.
+The maximum separation in number of levels of hierarchy between ancestor
+and descendant concepts. This is an attribute that is used to simplify
+hierarchic analysis.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12536,10 +14078,18 @@ <h3 class="tabset tabset-pills">CONCEPT_ANCESTOR</h3>
 </tbody>
 </table>
 </div>
-<div id="source_to_concept_map" class="section level3 tabset tabset-pills">
+<div id="source_to_concept_map"
+class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 <p><strong>Table Description</strong></p>
-<p>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.</p>
+<p>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.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12604,10 +14154,12 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 source_concept_id
 </td>
 <td style="text-align:left;">
-A foreign key to the Source Concept that is being translated into a Standard Concept.
+A foreign key to the Source Concept that is being translated into a
+Standard Concept.
 </td>
 <td style="text-align:left;">
-This is either 0 or should be a number above 2 billion, which are the Concepts reserved for site-specific codes and mappings.
+This is either 0 or should be a number above 2 billion, which are the
+Concepts reserved for site-specific codes and mappings.
 </td>
 <td style="text-align:left;">
 integer
@@ -12632,7 +14184,8 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 source_vocabulary_id
 </td>
 <td style="text-align:left;">
-A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept.
+A foreign key to the VOCABULARY table defining the vocabulary of the
+source code that is being translated to a Standard Concept.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12658,7 +14211,9 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 source_code_description
 </td>
 <td style="text-align:left;">
-An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept.
+An optional description for the source code. This is included as a
+convenience to compare the description of the source code to the name of
+the concept.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12764,7 +14319,9 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 valid_end_date
 </td>
 <td style="text-align:left;">
-The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. Default value is 31-Dec-2099.
+The date when the mapping instance became invalid because it was deleted
+or superseded (updated) by a new relationship. Default value is
+31-Dec-2099.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12790,7 +14347,9 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value.
+Reason the mapping instance was invalidated. Possible values are D
+(deleted), U (replaced with an update) or NULL when valid_end_date has
+the default value.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12817,7 +14376,10 @@ <h3 class="tabset tabset-pills">SOURCE_TO_CONCEPT_MAP</h3>
 <div id="drug_strength" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 <p><strong>Table Description</strong></p>
-<p>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.</p>
+<p>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.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -12883,10 +14445,12 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 ingredient_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the active ingredient contained within the drug product.
+The Concept representing the active ingredient contained within the drug
+product.
 </td>
 <td style="text-align:left;">
-Combination Drugs will have more than one record in this table, one for each active Ingredient.
+Combination Drugs will have more than one record in this table, one for
+each active Ingredient.
 </td>
 <td style="text-align:left;">
 integer
@@ -12911,7 +14475,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 amount_value
 </td>
 <td style="text-align:left;">
-The numeric value or the amount of active ingredient contained within the drug product.
+The numeric value or the amount of active ingredient contained within
+the drug product.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12937,7 +14502,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 amount_unit_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the Unit of measure for the amount of active ingredient contained within the drug product.
+The Concept representing the Unit of measure for the amount of active
+ingredient contained within the drug product.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12964,7 +14530,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 numerator_value
 </td>
 <td style="text-align:left;">
-The concentration of the active ingredient contained within the drug product.
+The concentration of the active ingredient contained within the drug
+product.
 </td>
 <td style="text-align:left;">
 </td>
@@ -12990,7 +14557,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 numerator_unit_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the Unit of measure for the concentration of active ingredient.
+The Concept representing the Unit of measure for the concentration of
+active ingredient.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13017,7 +14585,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 denominator_value
 </td>
 <td style="text-align:left;">
-The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.).
+The amount of total liquid (or other divisible product, such as
+ointment, gel, spray, etc.).
 </td>
 <td style="text-align:left;">
 </td>
@@ -13043,7 +14612,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 denominator_unit_concept_id
 </td>
 <td style="text-align:left;">
-The Concept representing the denominator unit for the concentration of active ingredient.
+The Concept representing the denominator unit for the concentration of
+active ingredient.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13070,7 +14640,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 box_size
 </td>
 <td style="text-align:left;">
-The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient.
+The number of units of Clinical Branded Drug or Quantified Clinical or
+Branded Drug contained in a box as dispensed to the patient.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13096,7 +14667,8 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 valid_start_date
 </td>
 <td style="text-align:left;">
-The date when the Concept was first recorded. The default value is 1-Jan-1970.
+The date when the Concept was first recorded. The default value is
+1-Jan-1970.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13148,7 +14720,9 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 invalid_reason
 </td>
 <td style="text-align:left;">
-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.
+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.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13175,9 +14749,28 @@ <h3 class="tabset tabset-pills">DRUG_STRENGTH</h3>
 <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>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>
+<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>
@@ -13317,7 +14910,15 @@ <h3 class="tabset tabset-pills">COHORT</h3>
 <div id="cohort_definition" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 <p><strong>Table Description</strong></p>
-<p>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.</p>
+<p>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.</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
 <thead>
 <tr>
@@ -13356,7 +14957,8 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 cohort_definition_id
 </td>
 <td style="text-align:left;">
-This is the identifier given to the cohort, usually by the ATLAS application
+This is the identifier given to the cohort, usually by the ATLAS
+application
 </td>
 <td style="text-align:left;">
 </td>
@@ -13435,7 +15037,8 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 definition_type_concept_id
 </td>
 <td style="text-align:left;">
-Type defining what kind of Cohort Definition the record represents and how the syntax may be executed.
+Type defining what kind of Cohort Definition the record represents and
+how the syntax may be executed.
 </td>
 <td style="text-align:left;">
 </td>
@@ -13488,7 +15091,8 @@ <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 subject_concept_id
 </td>
 <td style="text-align:left;">
-This field contains a Concept that represents the domain of the subjects that are members of the cohort (e.g., Person, Provider, Visit).
+This field contains a Concept that represents the domain of the subjects
+that are members of the cohort (e.g., Person, Provider, Visit).
 </td>
 <td style="text-align:left;">
 </td>
diff --git a/docs/cdmDecisionTree.html b/docs/cdmDecisionTree.html
index 9ca3f2e2..e067e7df 100644
--- a/docs/cdmDecisionTree.html
+++ b/docs/cdmDecisionTree.html
@@ -11,9 +11,9 @@
 
 
 
-<title>cdmDecisionTree.knit</title>
+<title> CDM Request Decision Tree</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -411,16 +415,21 @@
 
 
 
-<h1 class="title toc-ignore"><div>
-<img src="ohdsi40x40.png"></img> CDM Request Decision Tree
-</div></h1>
+<h1 class="title toc-ignore"><img src="ohdsi40x40.png"></img> CDM
+Request Decision Tree</h1>
 
 </div>
 
 
-<p>If you have arrived to this page then you must be thinking <strong>HELP! I have some data that doesn’t fit in the CDM!</strong> Never fear as this handy guide will point you in the right direction and all you have to do is answer a few questions.</p>
-<p><strong>First things first, do you think you will need to change the OMOP Common Data Model itself or are you solely looking for vocabulary support?</strong></p>
-<p><a href="networkUseCase.html">I think I need to change the OMOP CDM</a></p>
+<p>If you have arrived to this page then you must be thinking
+<strong>HELP! I have some data that doesn’t fit in the CDM!</strong>
+Never fear as this handy guide will point you in the right direction and
+all you have to do is answer a few questions.</p>
+<p><strong>First things first, do you think you will need to change the
+OMOP Common Data Model itself or are you solely looking for vocabulary
+support?</strong></p>
+<p><a href="networkUseCase.html">I think I need to change the OMOP
+CDM</a></p>
 <p><a href="vocabN.html">I need vocabulary support</a></p>
 
 
diff --git a/docs/cdmPrivacy.html b/docs/cdmPrivacy.html
index 9c053428..ddd2d166 100644
--- a/docs/cdmPrivacy.html
+++ b/docs/cdmPrivacy.html
@@ -13,7 +13,7 @@
 
 <title>Preserving Privacy in an OMOP CDM Implementation</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -487,7 +491,8 @@
 
 
 
-<h1 class="title toc-ignore"><strong>Preserving Privacy in an OMOP CDM Implementation</strong></h1>
+<h1 class="title toc-ignore"><strong>Preserving Privacy in an OMOP CDM
+Implementation</strong></h1>
 
 </div>
 
@@ -495,116 +500,342 @@ <h1 class="title toc-ignore"><strong>Preserving Privacy in an OMOP CDM Implement
 <p><em>By Kristin Kostka</em></p>
 <div id="background" class="section level1">
 <h1>Background</h1>
-<p>The OMOP CDM is a person-centric model. Being person-centric means the model can retain attributes that may be considered personal identified information (PII) or protected health information (PHI). There are many different ways a site may treat their OMOP CDM to uphold their privacy protocols. In this article we provide guidance on overall process and the potential fields that should be monitored to adhere to these various privacy preserving protocols.</p>
+<p>The OMOP CDM is a person-centric model. Being person-centric means
+the model can retain attributes that may be considered personal
+identified information (PII) or protected health information (PHI).
+There are many different ways a site may treat their OMOP CDM to uphold
+their privacy protocols. In this article we provide guidance on overall
+process and the potential fields that should be monitored to adhere to
+these various privacy preserving protocols.</p>
 <div id="defining-pii-and-phi" class="section level3">
 <h3>Defining PII and PHI</h3>
 <ul>
-<li>PII is defined as any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred to either direct or indirect means [1].</li>
-<li>The United States Department of Health &amp; Human Services´ Office for Civil Rights has defined PHI as any Personal Identifying Information (PII) that – individually or combined – could potentially identify a specific individual, their past, present or future healthcare, or the method of payment. There are eighteen unique identifiers considered to be PHI: 1) names, 2) geographic data, 3) all elements of dates, 4) telephone numbers, 5) FAX numbers, 6) email addresses, 7) Social Security numbers (SSN), 8) medical record numbers (MRN), 9) health plan beneficiary numbers, 10) account numbers, 11) certificate/license numbers, 12) vehicle identifiers and serial numbers including license places, 13) device identifiers and serial numbers, 14) web URLs, 15) internet protocol addresses, 16) biometric identifiers (i.e. retinal scan, fingerprints), 17) full face photos and comparable images, and 18) any unique identifying number, characteristic or code. PHI is no longer considered PHI when it de-identified of these unique attributes. PHI is commonly referred to in relation to the Health Insurance Portability and Accountability Act (HIPAA) and associated legislation such as the Health Information Technology for Economic and Clinical Health Act (HITECH) [2].</li>
+<li>PII is defined as any representation of information that permits the
+identity of an individual to whom the information applies to be
+reasonably inferred to either direct or indirect means [1].</li>
+<li>The United States Department of Health &amp; Human Services´ Office
+for Civil Rights has defined PHI as any Personal Identifying Information
+(PII) that – individually or combined – could potentially identify a
+specific individual, their past, present or future healthcare, or the
+method of payment. There are eighteen unique identifiers considered to
+be PHI: 1) names, 2) geographic data, 3) all elements of dates, 4)
+telephone numbers, 5) FAX numbers, 6) email addresses, 7) Social
+Security numbers (SSN), 8) medical record numbers (MRN), 9) health plan
+beneficiary numbers, 10) account numbers, 11) certificate/license
+numbers, 12) vehicle identifiers and serial numbers including license
+places, 13) device identifiers and serial numbers, 14) web URLs, 15)
+internet protocol addresses, 16) biometric identifiers (i.e. retinal
+scan, fingerprints), 17) full face photos and comparable images, and 18)
+any unique identifying number, characteristic or code. PHI is no longer
+considered PHI when it de-identified of these unique attributes. PHI is
+commonly referred to in relation to the Health Insurance Portability and
+Accountability Act (HIPAA) and associated legislation such as the Health
+Information Technology for Economic and Clinical Health Act (HITECH)
+[2].</li>
 </ul>
 </div>
 </div>
 <div id="the-data-holders-responsibility" class="section level1">
 <h1>The Data Holder’s Responsibility</h1>
-<p>In OHDSI, it is the responsibility of each data holder to know, understand and follow local data governance processes related to use of the OMOP CDM. In the United States, these processes will follow your organization’s local interpretation for maintaining compliance to PII and PHI protection. In OMOP CDM implementations containing European Union citizen data, local governance processes will include measures to comply with General Data Protection Regulation (GDPR) [3]. As a community, the OHDSI data network covers more than 330 databases from 34 countries. There is extensive community knowledge on the interpretation of rule sets and exemplar IRB and local governance workflows that can be made available to institutions navigating these processes for the first time. If your organization does not have an established data governance process, please reach out on the <a href="forums.ohdsi.org">OHDSI Forums</a> under “Implementers” and the community can respond with shared guidance from their own deployments. As a community, we aim to conduct research that keeps patient-level data local and share only aggregate results.</p>
+<p>In OHDSI, it is the responsibility of each data holder to know,
+understand and follow local data governance processes related to use of
+the OMOP CDM. In the United States, these processes will follow your
+organization’s local interpretation for maintaining compliance to PII
+and PHI protection. In OMOP CDM implementations containing European
+Union citizen data, local governance processes will include measures to
+comply with General Data Protection Regulation (GDPR) [3]. As a
+community, the OHDSI data network covers more than 330 databases from 34
+countries. There is extensive community knowledge on the interpretation
+of rule sets and exemplar IRB and local governance workflows that can be
+made available to institutions navigating these processes for the first
+time. If your organization does not have an established data governance
+process, please reach out on the <a href="forums.ohdsi.org">OHDSI
+Forums</a> under “Implementers” and the community can respond with
+shared guidance from their own deployments. As a community, we aim to
+conduct research that keeps patient-level data local and share only
+aggregate results.</p>
 </div>
 <div id="complying-with-privacy-preservation" class="section level1">
 <h1>Complying with Privacy Preservation</h1>
-<p>Complying with local governance processes depends on the rule set being used. There may be allowable times when data use agreements and data transfer agreements exist between collaborating institutions to facilitate sharing of PII and PHI. In this section we will discuss common rule sets that organizations adhere to.</p>
+<p>Complying with local governance processes depends on the rule set
+being used. There may be allowable times when data use agreements and
+data transfer agreements exist between collaborating institutions to
+facilitate sharing of PII and PHI. In this section we will discuss
+common rule sets that organizations adhere to.</p>
 <div id="limited-data-sets" class="section level2">
 <h2>Limited Data Sets</h2>
-<p>A limited data set (LDS) is defined as protected health information that excludes certain direct identifiers of an individual or of relatives, employers or household members of the individual — but may include city, state, ZIP code and elements of dates. A LDS can be disclosed only for purposes of research, public health or health care operations. LDS requirements are dictated by the HIPAA Privacy Rule.</p>
+<p>A limited data set (LDS) is defined as protected health information
+that excludes certain direct identifiers of an individual or of
+relatives, employers or household members of the individual — but may
+include city, state, ZIP code and elements of dates. A LDS can be
+disclosed only for purposes of research, public health or health care
+operations. LDS requirements are dictated by the HIPAA Privacy Rule.</p>
 </div>
 <div id="de-identified-data-sets" class="section level2">
 <h2>De-identified Data Sets</h2>
-<p>A de-identified data, as defined by Section 164.514(a) of the HIPAA Privacy rule, is health information that does not identify an individual and with respect to which there is no reasonable basis to believe that the information can be used to identify an individual is not individually identifiable health information. There are two methods for achieving de-identification in accordance with HIPAA [4].</p>
+<p>A de-identified data, as defined by Section 164.514(a) of the HIPAA
+Privacy rule, is health information that does not identify an individual
+and with respect to which there is no reasonable basis to believe that
+the information can be used to identify an individual is not
+individually identifiable health information. There are two methods for
+achieving de-identification in accordance with HIPAA [4].</p>
 <ol style="list-style-type: decimal">
-<li>Expert Determination (§164.514(a))- Implementation specifications: requirements for de-identification of protected health information. A covered entity may determine that health information is not individually identifiable health information only if:</li>
+<li>Expert Determination (§164.514(a))- Implementation specifications:
+requirements for de-identification of protected health information. A
+covered entity may determine that health information is not individually
+identifiable health information only if:</li>
 </ol>
 <ol style="list-style-type: decimal">
-<li>A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable:</li>
+<li>A person with appropriate knowledge of and experience with generally
+accepted statistical and scientific principles and methods for rendering
+information not individually identifiable:</li>
 </ol>
 <ol style="list-style-type: lower-roman">
-<li>Applying such principles and methods, determines that the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual who is a subject of the information; and</li>
-<li>Documents the methods and results of the analysis that justify such determination.</li>
+<li>Applying such principles and methods, determines that the risk is
+very small that the information could be used, alone or in combination
+with other reasonably available information, by an anticipated recipient
+to identify an individual who is a subject of the information; and</li>
+<li>Documents the methods and results of the analysis that justify such
+determination.</li>
 </ol>
 <ol start="2" style="list-style-type: decimal">
-<li>Safe Harbor (§164.514(b)) The eighteen unique identifiers are obfuscated. This includes processes such as:</li>
+<li>Safe Harbor (§164.514(b)) The eighteen unique identifiers are
+obfuscated. This includes processes such as:</li>
 </ol>
 <ol style="list-style-type: upper-alpha">
-<li>Dates of service are algorithmically shifted to protect patient privacy.</li>
-<li>Patient ZIP codes are truncated to the first three digits or removed entirely if the ZIP code represents fewer than 20,000 individuals.</li>
-<li>Removing and, when necessary, replacing unique identifiers AND The entity does not have actual knowledge that the information could be used alone or in combination with other information to identify an individual who is a subject of the information.</li>
+<li>Dates of service are algorithmically shifted to protect patient
+privacy.</li>
+<li>Patient ZIP codes are truncated to the first three digits or removed
+entirely if the ZIP code represents fewer than 20,000 individuals.</li>
+<li>Removing and, when necessary, replacing unique identifiers AND The
+entity does not have actual knowledge that the information could be used
+alone or in combination with other information to identify an individual
+who is a subject of the information.</li>
 </ol>
 </div>
-<div id="field-level-implications-of-de-identification-processes" class="section level2">
+<div id="field-level-implications-of-de-identification-processes"
+class="section level2">
 <h2>Field-level Implications of De-identification Processes</h2>
 <div id="person-table-attributes" class="section level3">
 <h3>PERSON Table Attributes</h3>
-<p>In the OMOP CDM, the PERSON table serves as the central identity management for all Persons in the database. It contains records that uniquely identify each person or patient, and some demographic information. It is a table that has a number of field-level implications for privacy preserving protocols.</p>
-<p>Considerations include: - PERSON.person_id should never contain Medical Record Number, Social Security Number or similar uniquely identifiable number. This should be a number that is essentially meaningless but has the ability to be a primary key across tables. - PERSON.year_of_birth, PERSON.month_of_birth and PERSON.date_of_birth, PERSON.birth_datetime may require some redaction or modification depending on interpretation of rule set. Consult local guidance on the need to modify these fields when creating compliant views of de-identified data. - PERSON.person_source_value may contain sensitive information used to generate the person_id field. It is advised to practice caution when creating views of these data. It would be wise to obfuscate or redact this field if you are not sure what is contained in the raw information being extracted, transformed and loaded into the CDM.</p>
+<p>In the OMOP CDM, the PERSON table serves as the central identity
+management for all Persons in the database. It contains records that
+uniquely identify each person or patient, and some demographic
+information. It is a table that has a number of field-level implications
+for privacy preserving protocols.</p>
+<p>Considerations include: - PERSON.person_id should never contain
+Medical Record Number, Social Security Number or similar uniquely
+identifiable number. This should be a number that is essentially
+meaningless but has the ability to be a primary key across tables. -
+PERSON.year_of_birth, PERSON.month_of_birth and PERSON.date_of_birth,
+PERSON.birth_datetime may require some redaction or modification
+depending on interpretation of rule set. Consult local guidance on the
+need to modify these fields when creating compliant views of
+de-identified data. - PERSON.person_source_value may contain sensitive
+information used to generate the person_id field. It is advised to
+practice caution when creating views of these data. It would be wise to
+obfuscate or redact this field if you are not sure what is contained in
+the raw information being extracted, transformed and loaded into the
+CDM.</p>
 </div>
 </div>
 <div id="date-fields-across-domains" class="section level2">
 <h2>Date Fields Across Domains</h2>
-<p>Date fields are used across many OMOP domains including: OBSERVATION_PERIOD, VISIT_OCCURRENCE, VISIT_DETAIL, CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE, MEASUREMENT, OBSERVATION, DEATH, NOTE, NOTE_NLP, SPECIMEN, PAYER_PLAN_PERIOD, DRUG_ERA, DOSE_ERA, and CONDITION_ERA.</p>
-<p>As discussed previously, some rule sets may require algorithmically shifting dates. It is advised that when date shifting is applied, it is done holistically. This means that when shifting dates, you should not treat each record independently. Instead, a robust date shifting algorithm will link off the <em>.person_id (where </em> is the domain name such as CONDITION_OCCURRENCE, etc) and apply the same offset to all events. This allows researchers to have the ability to understand the sequence of events while preserving patient privacy.</p>
-<p>The implications of not holistically shifting all events together by the same offset means that information may be out of sequence or illogical. An example would be a death record that happens prior to other event records (conditions, drugs, procedures, etc). When applying an algorithmic shift of dates, it is important to educate your OMOP CDM user group of the known offset. This is especially important in temporal studies which may be looking to make statements about disease history relative to the time when an event is observed.</p>
-<p>Some rule sets do not require algorithmic shifting of dates, such as Limited Data Sets. In these situations, a user of a LDS OMOP CDM would not be expecting dates to the shifted. If a shift is applied, it should be disclosed and the offset amount (e.g. +/- 7 days, +/- 30 days, etc) should be made available to those who have received permission to use a LDS dataset. Otherwise, these data are not upholding the assumptions of the rule set applied.</p>
+<p>Date fields are used across many OMOP domains including:
+OBSERVATION_PERIOD, VISIT_OCCURRENCE, VISIT_DETAIL,
+CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE,
+DEVICE_EXPOSURE, MEASUREMENT, OBSERVATION, DEATH, NOTE, NOTE_NLP,
+SPECIMEN, PAYER_PLAN_PERIOD, DRUG_ERA, DOSE_ERA, and CONDITION_ERA.</p>
+<p>As discussed previously, some rule sets may require algorithmically
+shifting dates. It is advised that when date shifting is applied, it is
+done holistically. This means that when shifting dates, you should not
+treat each record independently. Instead, a robust date shifting
+algorithm will link off the <em>.person_id (where </em> is the domain
+name such as CONDITION_OCCURRENCE, etc) and apply the same offset to all
+events. This allows researchers to have the ability to understand the
+sequence of events while preserving patient privacy.</p>
+<p>The implications of not holistically shifting all events together by
+the same offset means that information may be out of sequence or
+illogical. An example would be a death record that happens prior to
+other event records (conditions, drugs, procedures, etc). When applying
+an algorithmic shift of dates, it is important to educate your OMOP CDM
+user group of the known offset. This is especially important in temporal
+studies which may be looking to make statements about disease history
+relative to the time when an event is observed.</p>
+<p>Some rule sets do not require algorithmic shifting of dates, such as
+Limited Data Sets. In these situations, a user of a LDS OMOP CDM would
+not be expecting dates to the shifted. If a shift is applied, it should
+be disclosed and the offset amount (e.g. +/- 7 days, +/- 30 days, etc)
+should be made available to those who have received permission to use a
+LDS dataset. Otherwise, these data are not upholding the assumptions of
+the rule set applied.</p>
 </div>
 <div id="location-table-attributes" class="section level2">
 <h2>LOCATION Table Attributes</h2>
-<p>The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites. When applying privacy preserving procedures, this table should be reviewed and scrubbed relative to the rule set. The LOCATION.zip field should be redacted relative to the type of process applied (e.g. 3-digit zip for de-identified data). The LOCATION.location_source_value should be reviewed for potential PII/PHI. It would be wise to obfuscate or redact this field if you are not sure what is contained in the raw information being extracted, transformed and loaded into the CDM.</p>
+<p>The LOCATION table represents a generic way to capture physical
+location or address information of Persons and Care Sites. When applying
+privacy preserving procedures, this table should be reviewed and
+scrubbed relative to the rule set. The LOCATION.zip field should be
+redacted relative to the type of process applied (e.g. 3-digit zip for
+de-identified data). The LOCATION.location_source_value should be
+reviewed for potential PII/PHI. It would be wise to obfuscate or redact
+this field if you are not sure what is contained in the raw information
+being extracted, transformed and loaded into the CDM.</p>
 </div>
 <div id="provider-table-attributes" class="section level2">
 <h2>PROVIDER Table Attributes</h2>
-<p>The PROVIDER table contains a list of uniquely identified healthcare providers. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc. In some privacy preserving processes, the PROVIDER.npi and PROVIDER.dea fields may be redacted. Please review this field and confirm that you are adhering to privacy rule sets. The PROVIDER.year_of_birth field is an optional field that may also require treatment in certain rule sets.</p>
+<p>The PROVIDER table contains a list of uniquely identified healthcare
+providers. These are individuals providing hands-on healthcare to
+patients, such as physicians, nurses, midwives, physical therapists etc.
+In some privacy preserving processes, the PROVIDER.npi and PROVIDER.dea
+fields may be redacted. Please review this field and confirm that you
+are adhering to privacy rule sets. The PROVIDER.year_of_birth field is
+an optional field that may also require treatment in certain rule
+sets.</p>
 </div>
 <div id="observation-table-attributes" class="section level2">
 <h2>OBSERVATION Table Attributes</h2>
-<p>The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here.</p>
-<p>We strongly caution ETL teams to review the OBSERVATION table for potential PII/PHI. In some source systems, there can be information coming in these vocabularies that are not laboratory or clinical observations but instead are patient identifiers. If you search in ATHENA, you will find there are a number of standard terms in the SNOMED and LOINC vocabularies that can represent phone numbers, emails, and other PII information.</p>
-<p>It is difficult to create an exhaustive list of terms because these ontologies do not maintain or publish lists of terms that may contain patient identifiers. It is, therefore, up to data holders to perform a review of this domain with an eye for these potential privacy issues. The National COVID Cohort Collaborative, a NIH consortium which uses the OMOP CDM, has published a resource for sites needing assistance with identifying these potentially problematic records. A “live” version of this table that will track updates over time is hosted at <a href="https://github.com/data2health/next-gen-data-sharing/blob/master/CodesWithPPIPotential.csv" class="uri">https://github.com/data2health/next-gen-data-sharing/blob/master/CodesWithPPIPotential.csv</a>. We welcome additions to this list from the community.</p>
+<p>The OBSERVATION table captures clinical facts about a Person obtained
+in the context of examination, questioning or a procedure. Any data that
+cannot be represented by any other domains, such as social and lifestyle
+facts, medical history, family history, etc. are recorded here.</p>
+<p>We strongly caution ETL teams to review the OBSERVATION table for
+potential PII/PHI. In some source systems, there can be information
+coming in these vocabularies that are not laboratory or clinical
+observations but instead are patient identifiers. If you search in
+ATHENA, you will find there are a number of standard terms in the SNOMED
+and LOINC vocabularies that can represent phone numbers, emails, and
+other PII information.</p>
+<p>It is difficult to create an exhaustive list of terms because these
+ontologies do not maintain or publish lists of terms that may contain
+patient identifiers. It is, therefore, up to data holders to perform a
+review of this domain with an eye for these potential privacy issues.
+The National COVID Cohort Collaborative, a NIH consortium which uses the
+OMOP CDM, has published a resource for sites needing assistance with
+identifying these potentially problematic records. A “live” version of
+this table that will track updates over time is hosted at <a
+href="https://github.com/data2health/next-gen-data-sharing/blob/master/CodesWithPPIPotential.csv"
+class="uri">https://github.com/data2health/next-gen-data-sharing/blob/master/CodesWithPPIPotential.csv</a>.
+We welcome additions to this list from the community.</p>
 </div>
 <div id="scrutinizing-_source_value" class="section level2">
 <h2>Scrutinizing *_source_value</h2>
-<p>The *_source_value (where * is the domain name such as CONDITION_OCCURRENCE, etc) fields present an opportunity for sites to carry forward potential PII/PHI in ETL processes. Because the convention of the OMOP CDM has minimal boundaries on what are retained in these fields, it is important to treat all source_value fields as potentially containing PII/PHI. We highly advise all data holders to scrutinize these fields when applying privacy preserving processes. It is not uncommon for fields to be overloaded and contain potential patient identifiers. Please use caution when transmitting or making views of these fields available to users.</p>
+<p>The *_source_value (where * is the domain name such as
+CONDITION_OCCURRENCE, etc) fields present an opportunity for sites to
+carry forward potential PII/PHI in ETL processes. Because the convention
+of the OMOP CDM has minimal boundaries on what are retained in these
+fields, it is important to treat all source_value fields as potentially
+containing PII/PHI. We highly advise all data holders to scrutinize
+these fields when applying privacy preserving processes. It is not
+uncommon for fields to be overloaded and contain potential patient
+identifiers. Please use caution when transmitting or making views of
+these fields available to users.</p>
 </div>
 <div id="scrutinizing-string-fields" class="section level2">
 <h2>Scrutinizing String Fields</h2>
-<p>Across OMOP Domains, there are many fields which permit the use of strings (e.g. DRUG_EXPOSURE.sig, MEASUREMENT.value_as_string, OBSERVATION.value_as_string, We’ve discussed some of these in prior sections. It is advised that fields with strings often have the potential to contain unintentional PII/PHI. Targeted regular expressions can be built into ETL processes in order to “sniff” out any additional PII (or potential PII)–such as any data in the format of a phone number, or a person or place name. (E.g., the regular expression “Mr.|Mrs.|Dr.|, M.?D.?” will find any string with an English name prefix.) Depending on risk tolerance, the expressions could err toward sensitivity or specificity, and could be tweaked over time to meet different rule sets.</p>
-<p>Extensive regular expression matching during ETL may add significant processing time and should therefore not be relied upon as a sole solution, but rather an extra protection against edge cases. Other algorithmic rules may also prove useful, such as automatically quarantining records with lengthy string values (which could signal the presence of free text). If these approaches are implemented, records that match the regular expressions or rules can be quarantined in a separate table or staging area to be manually reviewed by a data broker. Thus, in addition to adding another layer of PII protection, another advantage of these approaches is the potential to uncover ways that underlying vocabularies may be contributing to unintentional sharing of PII and create awareness for future privacy preserving processes shared across the community.</p>
+<p>Across OMOP Domains, there are many fields which permit the use of
+strings (e.g. DRUG_EXPOSURE.sig, MEASUREMENT.value_as_string,
+OBSERVATION.value_as_string, We’ve discussed some of these in prior
+sections. It is advised that fields with strings often have the
+potential to contain unintentional PII/PHI. Targeted regular expressions
+can be built into ETL processes in order to “sniff” out any additional
+PII (or potential PII)–such as any data in the format of a phone number,
+or a person or place name. (E.g., the regular expression “Mr.|Mrs.|Dr.|,
+M.?D.?” will find any string with an English name prefix.) Depending on
+risk tolerance, the expressions could err toward sensitivity or
+specificity, and could be tweaked over time to meet different rule
+sets.</p>
+<p>Extensive regular expression matching during ETL may add significant
+processing time and should therefore not be relied upon as a sole
+solution, but rather an extra protection against edge cases. Other
+algorithmic rules may also prove useful, such as automatically
+quarantining records with lengthy string values (which could signal the
+presence of free text). If these approaches are implemented, records
+that match the regular expressions or rules can be quarantined in a
+separate table or staging area to be manually reviewed by a data broker.
+Thus, in addition to adding another layer of PII protection, another
+advantage of these approaches is the potential to uncover ways that
+underlying vocabularies may be contributing to unintentional sharing of
+PII and create awareness for future privacy preserving processes shared
+across the community.</p>
 </div>
 <div id="note-and-note_nlp-table-attributes" class="section level2">
 <h2>NOTE and NOTE_NLP Table Attributes</h2>
-<p>The NOTE table captures unstructured information that was recorded by a provider about a patient in free text (in ASCII, or preferably in UTF8 format) notes on a given date. The NOTE_NLP table encodes all output of NLP on clinical notes. Each row represents a single extracted term from a note. There is a high potential these tables may retain information that is considered PII/PHI. In addition to overall string searching, these tables are likely to be dropped altogether to adhere to the most stringent rule sets.</p>
-<p>It is highly advised that if you are conducting a study with NOTE and NOTE_NLP table information, please consult with your local governance and privacy officers to ensure compliance with local rule sets.</p>
+<p>The NOTE table captures unstructured information that was recorded by
+a provider about a patient in free text (in ASCII, or preferably in UTF8
+format) notes on a given date. The NOTE_NLP table encodes all output of
+NLP on clinical notes. Each row represents a single extracted term from
+a note. There is a high potential these tables may retain information
+that is considered PII/PHI. In addition to overall string searching,
+these tables are likely to be dropped altogether to adhere to the most
+stringent rule sets.</p>
+<p>It is highly advised that if you are conducting a study with NOTE and
+NOTE_NLP table information, please consult with your local governance
+and privacy officers to ensure compliance with local rule sets.</p>
 </div>
 <div id="conclusion" class="section level2">
 <h2>Conclusion</h2>
-<p>Privacy preserving processes are not one-size fits all. There are many different rule sets that can be applied to datasets. Data holders are recommended to consult with their local privacy officer(s) to ensure all processes applied to a database are compliant with local interpretation of the selected rule set.</p>
+<p>Privacy preserving processes are not one-size fits all. There are
+many different rule sets that can be applied to datasets. Data holders
+are recommended to consult with their local privacy officer(s) to ensure
+all processes applied to a database are compliant with local
+interpretation of the selected rule set.</p>
 </div>
 </div>
 <div id="references" class="section level1">
 <h1>References</h1>
 <ol style="list-style-type: decimal">
-<li>BibText version: <span class="citation">@MISC</span>{noauthor_undated-mg, title = “Guidance on the Protection of Personal Identifiable Information”, abstract = “Personal Identifiable Information (PII) is defined as:”, howpublished = “”, note = “Accessed: 2021-8-18” }</li>
+<li>BibText version: <span
+class="citation">@MISC</span>{noauthor_undated-mg, title = “Guidance on
+the Protection of Personal Identifiable Information”, abstract =
+“Personal Identifiable Information (PII) is defined as:”, howpublished =
+“”, note = “Accessed: 2021-8-18” }</li>
 </ol>
-<p>Regular citation: Guidance on the Protection of Personal Identifiable Information. [cited 18 Aug 2021]. Available: <a href="https://www.dol.gov/general/ppii" class="uri">https://www.dol.gov/general/ppii</a></p>
+<p>Regular citation: Guidance on the Protection of Personal Identifiable
+Information. [cited 18 Aug 2021]. Available: <a
+href="https://www.dol.gov/general/ppii"
+class="uri">https://www.dol.gov/general/ppii</a></p>
 <ol start="2" style="list-style-type: decimal">
-<li>BibText version: <span class="citation">@MISC</span>{HIPAA_Journal2017-yo, title = “What Does {PHI} Stand For?”, author = “{HIPAA Journal}”, abstract = “PHI is a term used in connection with health data, but what does PHI stand for? What information is included in the definition of PHI.”, month = dec, year = 2017, howpublished = “”, note = “Accessed: 2021-8-18”, language = “en” }</li>
+<li>BibText version: <span
+class="citation">@MISC</span>{HIPAA_Journal2017-yo, title = “What Does
+{PHI} Stand For?”, author = “{HIPAA Journal}”, abstract = “PHI is a term
+used in connection with health data, but what does PHI stand for? What
+information is included in the definition of PHI.”, month = dec, year =
+2017, howpublished = “”, note = “Accessed: 2021-8-18”, language = “en”
+}</li>
 </ol>
-<p>Regular citation: HIPAA Journal. What Does PHI Stand For? 23 Dec 2017 [cited 18 Aug 2021]. Available: <a href="https://www.hipaajournal.com/what-does-phi-stand-for/" class="uri">https://www.hipaajournal.com/what-does-phi-stand-for/</a></p>
+<p>Regular citation: HIPAA Journal. What Does PHI Stand For? 23 Dec 2017
+[cited 18 Aug 2021]. Available: <a
+href="https://www.hipaajournal.com/what-does-phi-stand-for/"
+class="uri">https://www.hipaajournal.com/what-does-phi-stand-for/</a></p>
 <ol start="3" style="list-style-type: decimal">
 <li>BibText version:</li>
 </ol>
-<p><span class="citation">@MISC</span>{noauthor_2018-mt, title = “General Data Protection Regulation ({GDPR}) Compliance Guidelines”, abstract = “The EU General Data Protection Regulation went into effect on May 25, 2018, replacing the Data Protection Directive 95/46/EC. Designed to increase data privacy for EU citizens, the regulation levies steep fines on organizations that don’t follow the law.”, month = jun, year = 2018, howpublished = “”, note = “Accessed: 2021-8-18”, language = “en” }</p>
-<p>Regular citation: General Data Protection Regulation (GDPR) Compliance Guidelines. 18 Jun 2018 [cited 18 Aug 2021]. Available: <a href="https://gdpr.eu/" class="uri">https://gdpr.eu/</a></p>
+<p><span class="citation">@MISC</span>{noauthor_2018-mt, title =
+“General Data Protection Regulation ({GDPR}) Compliance Guidelines”,
+abstract = “The EU General Data Protection Regulation went into effect
+on May 25, 2018, replacing the Data Protection Directive 95/46/EC.
+Designed to increase data privacy for EU citizens, the regulation levies
+steep fines on organizations that don’t follow the law.”, month = jun,
+year = 2018, howpublished = “”, note = “Accessed: 2021-8-18”, language =
+“en” }</p>
+<p>Regular citation: General Data Protection Regulation (GDPR)
+Compliance Guidelines. 18 Jun 2018 [cited 18 Aug 2021]. Available: <a
+href="https://gdpr.eu/" class="uri">https://gdpr.eu/</a></p>
 <ol start="4" style="list-style-type: decimal">
 <li>BibText version:</li>
 </ol>
-<p><span class="citation">@MISC</span>{Office_for_Civil_Rights_OCR_undated-zy, title = “Methods for De-identification of {PHI}”, author = “{Office for Civil Rights (OCR)}”, abstract = “Guidance about methods and approaches to achieve de-identification in accordance with the Health Insurance Portability and Accountability Act of 1996.”, howpublished = “”, note = “Accessed: 2021-8-19” }</p>
-<p>Regular citation: Office for Civil Rights (OCR). Methods for De-identification of PHI. [cited 19 Aug 2021]. Available: <a href="https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html" class="uri">https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html</a></p>
+<p><span
+class="citation">@MISC</span>{Office_for_Civil_Rights_OCR_undated-zy,
+title = “Methods for De-identification of {PHI}”, author = “{Office for
+Civil Rights (OCR)}”, abstract = “Guidance about methods and approaches
+to achieve de-identification in accordance with the Health Insurance
+Portability and Accountability Act of 1996.”, howpublished = “”, note =
+“Accessed: 2021-8-19” }</p>
+<p>Regular citation: Office for Civil Rights (OCR). Methods for
+De-identification of PHI. [cited 19 Aug 2021]. Available: <a
+href="https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html"
+class="uri">https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html</a></p>
 </div>
 
 
diff --git a/docs/cdmRPackage.html b/docs/cdmRPackage.html
index 5a6e9302..8f264b26 100644
--- a/docs/cdmRPackage.html
+++ b/docs/cdmRPackage.html
@@ -13,7 +13,7 @@
 
 <title>CDM R Package Demo</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,7 +420,14 @@ <h1 class="title toc-ignore"><strong>CDM R Package Demo</strong></h1>
 </div>
 
 
-<p>Below is an example showing two different ways the CDM R package can be used to create the tables in your environment. First, it uses the <code>buildRelease</code> function to create the DDL files on your machine. Once you have these downloaded you can then run them in your SQL client to set up the empty CDM tables. Second, the script shows the <code>executeDdl</code> function that will connect up to your SQL client directly (assuming your dbms is one of the supported dialects) and instantiate the tables through R.</p>
+<p>Below is an example showing two different ways the CDM R package can
+be used to create the tables in your environment. First, it uses the
+<code>buildRelease</code> function to create the DDL files on your
+machine. Once you have these downloaded you can then run them in your
+SQL client to set up the empty CDM tables. Second, the script shows the
+<code>executeDdl</code> function that will connect up to your SQL client
+directly (assuming your dbms is one of the supported dialects) and
+instantiate the tables through R.</p>
 <pre class="r"><code>## First, install the package from GitHub
 install.packages(&quot;devtools&quot;)
 devtools::install_github(&quot;OHDSI/CommonDataModel&quot;)
diff --git a/docs/cdmRefreshProcess.html b/docs/cdmRefreshProcess.html
index b437a9bc..0f1ceb0f 100644
--- a/docs/cdmRefreshProcess.html
+++ b/docs/cdmRefreshProcess.html
@@ -11,9 +11,9 @@
 
 
 
-<title>cdmRefreshProcess.knit</title>
+<title> CDM Refresh Process</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -487,52 +491,101 @@
 
 
 
-<h1 class="title toc-ignore"><div>
-<img src="ohdsi40x40.png"></img> CDM Refresh Process
-</div></h1>
+<h1 class="title toc-ignore"><img src="ohdsi40x40.png"></img> CDM
+Refresh Process</h1>
 
 </div>
 
 
-<p>The OMOP Common Data Model is managed by the OHDSI CDM Working Group. The formal remit of the CDM Working Group (WG) is to hear proposals for change, ratifying only those with valid use cases and data to support them. Then, once ratified, these proposals are incorporated into the next version of the CDM. In the past, this was done by the WG alone. The group would invite others from around the community to present use cases for change and suggestions for improvement. The WG would then vote on the proposals and a new CDM version would be released after a certain period of time or if enough proposals were voted in. This approach worked when the community was smaller but as it is growing rapidly the CDM WG needed to adapt the refresh cycle such that everyone has an opportunity to weigh in on the proposed changes.</p>
-<p>Looking to make a change or addition to the OMOP CDM? Please answer the questions in the <a href="cdmDecisionTree.html">decision tree</a> to point you in the right direction.</p>
+<p>The OMOP Common Data Model is managed by the OHDSI CDM Working Group.
+The formal remit of the CDM Working Group (WG) is to hear proposals for
+change, ratifying only those with valid use cases and data to support
+them. Then, once ratified, these proposals are incorporated into the
+next version of the CDM. In the past, this was done by the WG alone. The
+group would invite others from around the community to present use cases
+for change and suggestions for improvement. The WG would then vote on
+the proposals and a new CDM version would be released after a certain
+period of time or if enough proposals were voted in. This approach
+worked when the community was smaller but as it is growing rapidly the
+CDM WG needed to adapt the refresh cycle such that everyone has an
+opportunity to weigh in on the proposed changes.</p>
+<p>Looking to make a change or addition to the OMOP CDM? Please answer
+the questions in the <a href="cdmDecisionTree.html">decision tree</a> to
+point you in the right direction.</p>
 <div id="cdm-refresh-cycle" class="section level2">
 <h2>CDM Refresh Cycle</h2>
 <p><img src="images/CDM_refresh_cycle.png" /></p>
 <div id="define-new-version" class="section level3">
 <h3>1. Define New Version</h3>
-<p>The image above describes the new CDM refresh cycle. It begins with <strong>defining a new version</strong>. Proposals are heard over the course of a year according to the <a href="cdmRequestProcess.html">CDM Request Process</a> and the ratified changes are added to the roadmap until such time that there are enough updates to warrant a new version of the model.</p>
-<p>Looking to open a proposal to change or augment the CDM? Please follow the questions in the <a href="cdmDecisionTree.html">decision tree</a> to help you determine what you will need.</p>
+<p>The image above describes the new CDM refresh cycle. It begins with
+<strong>defining a new version</strong>. Proposals are heard over the
+course of a year according to the <a href="cdmRequestProcess.html">CDM
+Request Process</a> and the ratified changes are added to the roadmap
+until such time that there are enough updates to warrant a new version
+of the model.</p>
+<p>Looking to open a proposal to change or augment the CDM? Please
+follow the questions in the <a href="cdmDecisionTree.html">decision
+tree</a> to help you determine what you will need.</p>
 </div>
 <div id="sign-off-from-work-groups" class="section level3">
 <h3>2. Sign off from Work Groups</h3>
-<p>Each member of the CDM WG is a liaison for another workgroup in the community. They are responsible for presenting the proposed changes to the CDM and collecting the feedback. This has resulted in very helpful suggestions from the EHR, Data Quality, Device, HADES, and ACHILLES groups. This outreach has proven to be very effective and should result in a very stable version.</p>
+<p>Each member of the CDM WG is a liaison for another workgroup in the
+community. They are responsible for presenting the proposed changes to
+the CDM and collecting the feedback. This has resulted in very helpful
+suggestions from the EHR, Data Quality, Device, HADES, and ACHILLES
+groups. This outreach has proven to be very effective and should result
+in a very stable version.</p>
 </div>
 <div id="release-ddls" class="section level3">
 <h3>3. Release DDLs</h3>
-<p>After all changes and suggestions are agreed upon by the community and work groups the next step is to generate the DDLs. For example, the CDM WG hosted a hackathon on August 18-19, 2021. During this time the group created an R package to automatically generate the DDLs and the code to instantiate an empty CDM instance. Changes were made to v5.3 to generate v5.4 and the repository was refactored.</p>
+<p>After all changes and suggestions are agreed upon by the community
+and work groups the next step is to generate the DDLs. For example, the
+CDM WG hosted a hackathon on August 18-19, 2021. During this time the
+group created an R package to automatically generate the DDLs and the
+code to instantiate an empty CDM instance. Changes were made to v5.3 to
+generate v5.4 and the repository was refactored.</p>
 </div>
 <div id="software-update" class="section level3">
 <h3>4. Software Update</h3>
-<p>There will be period of time once the DDLs are ready to allow the software and methods developers to prepare for the official release of the CDM. This is meant to serve as a buffer so that once the community starts adopting the new model, the tools and methods will be ready to support it.</p>
+<p>There will be period of time once the DDLs are ready to allow the
+software and methods developers to prepare for the official release of
+the CDM. This is meant to serve as a buffer so that once the community
+starts adopting the new model, the tools and methods will be ready to
+support it.</p>
 </div>
 <div id="community-support" class="section level3">
 <h3>5. Community Support</h3>
-<p>This is the final stage of the CDM refresh cycle. Once the DDLs are ready and the software and tools supports the new version, the CDM WG will work to help the community convert their data to the new model.</p>
+<p>This is the final stage of the CDM refresh cycle. Once the DDLs are
+ready and the software and tools supports the new version, the CDM WG
+will work to help the community convert their data to the new model.</p>
 </div>
 </div>
 <div id="cdm-wg-meeting-information" class="section level1">
 <h1>CDM WG Meeting Information</h1>
-<p>The CDM working group meets the first and third Tuesday of the month. See below for links to the meetings.</p>
-<p><strong>Every first Tuesday of the month at 10am est</strong> <a href="https://teams.microsoft.com/l/meetup-join/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/1601910741972?context=%7b%22Tid%22%3a%22a30f0094-9120-4aab-ba4c-e5509023b2d5%22%2c%22Oid%22%3a%2281c21b6d-448d-4634-abbc-6b0962d1138a%22%7d">Teams Meeting</a></p>
-<p><strong>Every third Tuesday of the month at 1pm est</strong> <a href="https://teams.microsoft.com/l/meetup-join/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/1611000164347?context=%7b%22Tid%22%3a%22a30f0094-9120-4aab-ba4c-e5509023b2d5%22%2c%22Oid%22%3a%223c193b7f-c2ab-4bcf-b88c-f89a6b1fba38%22%7d">Teams Meeting</a></p>
-<p><strong>Note</strong> These were recently changed from a Skype meeting to a Microsoft Teams meeting. If you do you have access to the OHDSI Teams Tenet, please contact Clair Blacketer at <a href="mailto:mblacke@its.jnj.com" class="email">mblacke@its.jnj.com</a>.</p>
+<p>The CDM working group meets the first and third Tuesday of the month.
+See below for links to the meetings.</p>
+<p><strong>Every first Tuesday of the month at 10am est</strong> <a
+href="https://teams.microsoft.com/l/meetup-join/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/1601910741972?context=%7b%22Tid%22%3a%22a30f0094-9120-4aab-ba4c-e5509023b2d5%22%2c%22Oid%22%3a%2281c21b6d-448d-4634-abbc-6b0962d1138a%22%7d">Teams
+Meeting</a></p>
+<p><strong>Every third Tuesday of the month at 1pm est</strong> <a
+href="https://teams.microsoft.com/l/meetup-join/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/1611000164347?context=%7b%22Tid%22%3a%22a30f0094-9120-4aab-ba4c-e5509023b2d5%22%2c%22Oid%22%3a%223c193b7f-c2ab-4bcf-b88c-f89a6b1fba38%22%7d">Teams
+Meeting</a></p>
+<p><strong>Note</strong> These were recently changed from a Skype
+meeting to a Microsoft Teams meeting. If you do you have access to the
+OHDSI Teams Tenet, please contact Clair Blacketer at <a
+href="mailto:mblacke@its.jnj.com"
+class="email">mblacke@its.jnj.com</a>.</p>
 <div id="cdm-wg-important-links" class="section level3">
 <h3>CDM WG Important Links</h3>
 <ul>
-<li><a href="https://drive.google.com/open?id=1DaNKe6ivIAZPJeI31VJ-pzNB9wS9hDqu">Google Drive Location</a></li>
-<li><a href="https://docs.google.com/document/d/1WgKePjrI_cGdqn2XQCe1JdGaTzdMqU4p5ihkMt8fcAc/edit?usp=sharing">Running Agenda</a></li>
-<li><a href="https://github.com/OHDSI/CommonDataModel">CDM Github</a></li>
+<li><a
+href="https://drive.google.com/open?id=1DaNKe6ivIAZPJeI31VJ-pzNB9wS9hDqu">Google
+Drive Location</a></li>
+<li><a
+href="https://docs.google.com/document/d/1WgKePjrI_cGdqn2XQCe1JdGaTzdMqU4p5ihkMt8fcAc/edit?usp=sharing">Running
+Agenda</a></li>
+<li><a href="https://github.com/OHDSI/CommonDataModel">CDM
+Github</a></li>
 </ul>
 </div>
 </div>
diff --git a/docs/cdmRequestProcess.html b/docs/cdmRequestProcess.html
index e4d69a02..633101c5 100644
--- a/docs/cdmRequestProcess.html
+++ b/docs/cdmRequestProcess.html
@@ -11,9 +11,9 @@
 
 
 
-<title>cdmRequestProcess.knit</title>
+<title> How to Request Changes to the CDM</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -487,16 +491,29 @@
 
 
 
-<h1 class="title toc-ignore"><div>
-<img src="ohdsi40x40.png"></img> How to Request Changes to the CDM
-</div></h1>
+<h1 class="title toc-ignore"><img src="ohdsi40x40.png"></img> How to
+Request Changes to the CDM</h1>
 
 </div>
 
 
-<p>Are you in the right place? Please answer the questions in the <a href="cdmDecisionTree.html">decision tree</a> prior to beginning a CDM Request to make sure you aren’t missing something.</p>
-<p>As OHDSI is an open-source community working towards developing a Common Data Model that fulfills the needs of its users, it is often the case that changes need to be made to the model as the community and its research continues to mature. However, the number of people, institutions, and initiatives that rely on the OMOP CDM to advance the science of observational health has grown dramatically since its inception in 2015. Therefore, care must be taken when considering any update to the model, big or small. This document outlines the process that should be taken to ratify a change to the CDM.</p>
-<p><strong>If you would like guidance prior to starting this process, consider contacting us on our <a href="https://github.com/OHDSI/CommonDataModel">GitHub</a> or <a href="https://teams.microsoft.com/l/team/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/conversations?groupId=a6f2c516-e568-4974-8f1e-a7bdc2f997c5&amp;tenantId=a30f0094-9120-4aab-ba4c-e5509023b2d5">Teams Channel</a>.</strong></p>
+<p>Are you in the right place? Please answer the questions in the <a
+href="cdmDecisionTree.html">decision tree</a> prior to beginning a CDM
+Request to make sure you aren’t missing something.</p>
+<p>As OHDSI is an open-source community working towards developing a
+Common Data Model that fulfills the needs of its users, it is often the
+case that changes need to be made to the model as the community and its
+research continues to mature. However, the number of people,
+institutions, and initiatives that rely on the OMOP CDM to advance the
+science of observational health has grown dramatically since its
+inception in 2015. Therefore, care must be taken when considering any
+update to the model, big or small. This document outlines the process
+that should be taken to ratify a change to the CDM.</p>
+<p><strong>If you would like guidance prior to starting this process,
+consider contacting us on our <a
+href="https://github.com/OHDSI/CommonDataModel">GitHub</a> or <a
+href="https://teams.microsoft.com/l/team/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/conversations?groupId=a6f2c516-e568-4974-8f1e-a7bdc2f997c5&amp;tenantId=a30f0094-9120-4aab-ba4c-e5509023b2d5">Teams
+Channel</a>.</strong></p>
 <div id="scope" class="section level3">
 <h3>Scope</h3>
 <ul>
@@ -513,16 +530,34 @@ <h3>Scope</h3>
 </div>
 <div id="step-1-proposal" class="section level2">
 <h2>Step 1: Proposal</h2>
-<p>Once a group or organization has decided on the update they would like made to the model, they must produce a document including the following:</p>
+<p>Once a group or organization has decided on the update they would
+like made to the model, they must produce a document including the
+following:</p>
 <ol style="list-style-type: decimal">
-<li>A clear description of the change or addition including the User Guide and ETL Conventions in the same structure as what is present on the website for every table and field currently in the CDM.</li>
-<li>A clearly defined use case noting why the latest version of the OMOP CDM fails to adequately address said use case. This should include describing what you have already tried with the latest version of the OMOP CDM and why it does not meet your needs.</li>
-<li>An example of how the requested change or addition will be used in practice. This can be in the form of sample data, SQL code, a diagram, or text. The proposal can optionally include suggestions as to how other OHDSI tools (Achilles, DataQualityDashboard, Atlas, etc.) should work with your change or addition.</li>
+<li>A clear description of the change or addition including the User
+Guide and ETL Conventions in the same structure as what is present on
+the website for every table and field currently in the CDM.</li>
+<li>A clearly defined use case noting why the latest version of the OMOP
+CDM fails to adequately address said use case. This should include
+describing what you have already tried with the latest version of the
+OMOP CDM and why it does not meet your needs.</li>
+<li>An example of how the requested change or addition will be used in
+practice. This can be in the form of sample data, SQL code, a diagram,
+or text. The proposal can optionally include suggestions as to how other
+OHDSI tools (Achilles, DataQualityDashboard, Atlas, etc.) should work
+with your change or addition.</li>
 </ol>
-<p>Once the document is ready to submit, please email <a href="mailto:a58abde7.ohdsi.org@amer.teams.ms">CDM Proposals - Workgroup - Common Data Model</a>. This will go directly to a separate channel in the OHDSI Teams environment that is available to all members of the CDM Working Group. After submitting your document with your proposal to email listed above, someone in the OMOP CDM Working Group will respond to you within 2 weeks. The potential outcomes are as follows:</p>
+<p>Once the document is ready to submit, please email <a
+href="mailto:a58abde7.ohdsi.org@amer.teams.ms">CDM Proposals - Workgroup
+- Common Data Model</a>. This will go directly to a separate channel in
+the OHDSI Teams environment that is available to all members of the CDM
+Working Group. After submitting your document with your proposal to
+email listed above, someone in the OMOP CDM Working Group will respond
+to you within 2 weeks. The potential outcomes are as follows:</p>
 <ul>
 <li>Proposal merits further review (move on to next steps)</li>
-<li>Proposal is not ready for workgroup review due to one or more factors
+<li>Proposal is not ready for workgroup review due to one or more
+factors
 <ul>
 <li>Incomplete</li>
 <li>Insufficiently aligned with the OMOP framework</li>
@@ -532,25 +567,52 @@ <h2>Step 1: Proposal</h2>
 </div>
 <div id="step-2-initial-presentation" class="section level2">
 <h2>Step 2: Initial Presentation</h2>
-<p>Should your proposals merit further review, the OMOP CDM Working Group will reach out to you to schedule a time for you to present your case at an upcoming meeting. You will be given 15-30 minutes to present your document and you can include anything you feel will help illustrate the need and your potential solution. The group will then discuss, ask questions, and potentially offer other solutions. Depending on the nature of the request, this may go over multiple sessions and you may be asked to make changes to your initial design. At the end of this process your proposal will then be put to consensus in the CDM WG. If the group decides no, they will give feedback describing why they did not feel your proposal should be accepted at this time. If the group decides yes, you move on to step 3.</p>
+<p>Should your proposals merit further review, the OMOP CDM Working
+Group will reach out to you to schedule a time for you to present your
+case at an upcoming meeting. You will be given 15-30 minutes to present
+your document and you can include anything you feel will help illustrate
+the need and your potential solution. The group will then discuss, ask
+questions, and potentially offer other solutions. Depending on the
+nature of the request, this may go over multiple sessions and you may be
+asked to make changes to your initial design. At the end of this process
+your proposal will then be put to consensus in the CDM WG. If the group
+decides no, they will give feedback describing why they did not feel
+your proposal should be accepted at this time. If the group decides yes,
+you move on to step 3.</p>
 <p><strong>Potential Decision Criteria:</strong></p>
 <ul>
-<li>If the change is foundational to OHDSI tools, then the proposal will be put to the larger community open to public comment</li>
-<li>How generalizable is your change? Can it be readily applied to other use cases?</li>
-<li>Are the proposed changes/additions well designed from a modeling perspective? Do they follow the existing OMOP CDM conventions?</li>
-<li>What are the consequences of the change? Are they potentially breaking changes or are they just changes to existing conventions? Will they require the remapping of existing OMOP datasources?</li>
-<li>How complicated is your change? Is it an addition of a field or multiple tables?</li>
+<li>If the change is foundational to OHDSI tools, then the proposal will
+be put to the larger community open to public comment</li>
+<li>How generalizable is your change? Can it be readily applied to other
+use cases?</li>
+<li>Are the proposed changes/additions well designed from a modeling
+perspective? Do they follow the existing OMOP CDM conventions?</li>
+<li>What are the consequences of the change? Are they potentially
+breaking changes or are they just changes to existing conventions? Will
+they require the remapping of existing OMOP datasources?</li>
+<li>How complicated is your change? Is it an addition of a field or
+multiple tables?</li>
 </ul>
 </div>
 <div id="step-3-preliminary-decision" class="section level2">
 <h2>Step 3: Preliminary Decision</h2>
-<p>If the proposal is accepted in the preliminary decision, then a branch will be created in the CommonDataModel repository, based on the latest version of the OMOP CDM in use (currently v5.4). It will then be your responsibility to apply the change programmatically in this branch. This should include:</p>
+<p>If the proposal is accepted in the preliminary decision, then a
+branch will be created in the CommonDataModel repository, based on the
+latest version of the OMOP CDM in use (currently v5.4). It will then be
+your responsibility to apply the change programmatically in this branch.
+This should include:</p>
 <ul>
-<li>Updating the CSV file with the CDM specification, including the User Guide and ETL Conventions documentation</li>
+<li>Updating the CSV file with the CDM specification, including the User
+Guide and ETL Conventions documentation</li>
 <li>Generating the DDL files with the change</li>
 <li>Testing the new DDL files in at least one supported environment</li>
 </ul>
-<p>Once the DDLs with the proposed change are created and tested, you should then ETL some data (either real or synthetic) into the new table/fields. Then, an example cohort should be created that utilizes the change or addition and clearly displays how it can be used in a real study. It is expected that during this stage the proposal will change as you work through your idea in a tangible environment.</p>
+<p>Once the DDLs with the proposed change are created and tested, you
+should then ETL some data (either real or synthetic) into the new
+table/fields. Then, an example cohort should be created that utilizes
+the change or addition and clearly displays how it can be used in a real
+study. It is expected that during this stage the proposal will change as
+you work through your idea in a tangible environment.</p>
 <p><strong>Potential Decision Criteria:</strong></p>
 <ul>
 <li>How would you evaluate the quality of this new field/table?</li>
@@ -562,9 +624,11 @@ <h2>Step 3: Preliminary Decision</h2>
 <li>Proposal demonstrates merit for further consideration as:
 <ul>
 <li>a core data model change (move on to next steps)</li>
-<li>an extension (how do we deal with these/do we have ownership of them?)</li>
+<li>an extension (how do we deal with these/do we have ownership of
+them?)</li>
 </ul></li>
-<li>Proposal does not demonstrate merit for further consideration at this time, and:
+<li>Proposal does not demonstrate merit for further consideration at
+this time, and:
 <ul>
 <li>recommend as a LOCAL extension</li>
 <li>recommend a different course</li>
@@ -573,15 +637,29 @@ <h2>Step 3: Preliminary Decision</h2>
 </div>
 <div id="step-4-final-presentation" class="section level2">
 <h2>Step 4: Final Presentation</h2>
-<p>After generating, testing, and implementing your proposal in a real-world environment the CDM working group will invite you again to present your findings in another 15-30 minute presentation. This should include learnings from the exercise and any updates made to the initial proposal.</p>
+<p>After generating, testing, and implementing your proposal in a
+real-world environment the CDM working group will invite you again to
+present your findings in another 15-30 minute presentation. This should
+include learnings from the exercise and any updates made to the initial
+proposal.</p>
 </div>
 <div id="step-5-final-decision" class="section level2">
 <h2>Step 5: Final Decision</h2>
-<p>At this point, the working group liaisons will also take the proposal to other groups to elicit feedback. Then the CDM working group will vote and give a final decision on the proposed change. If ratified, the branch in the repository will be merged into the develop branch to be included in a next version of the OMOP Common Data Model.</p>
-<p>The change should initiate requests for features in tools. The end of this process should be a trigger for using the new feature as per the use case. The group should also produce at least one query for the query library on how to work with the new addition/change.</p>
+<p>At this point, the working group liaisons will also take the proposal
+to other groups to elicit feedback. Then the CDM working group will vote
+and give a final decision on the proposed change. If ratified, the
+branch in the repository will be merged into the develop branch to be
+included in a next version of the OMOP Common Data Model.</p>
+<p>The change should initiate requests for features in tools. The end of
+this process should be a trigger for using the new feature as per the
+use case. The group should also produce at least one query for the query
+library on how to work with the new addition/change.</p>
 <div id="resources" class="section level3">
 <h3>Resources</h3>
-<p>“Implementing &amp; adopting a customized OMOP Common Data Model” (Melany Philofsky, OHDSI Symposium 2021) <a href="https://www.ohdsi.org/2021-global-symposium-showcase-18/" class="uri">https://www.ohdsi.org/2021-global-symposium-showcase-18/</a></p>
+<p>“Implementing &amp; adopting a customized OMOP Common Data Model”
+(Melany Philofsky, OHDSI Symposium 2021) <a
+href="https://www.ohdsi.org/2021-global-symposium-showcase-18/"
+class="uri">https://www.ohdsi.org/2021-global-symposium-showcase-18/</a></p>
 </div>
 </div>
 
diff --git a/docs/contactVocab.html b/docs/contactVocab.html
index 5aa5c7af..6675aa84 100644
--- a/docs/contactVocab.html
+++ b/docs/contactVocab.html
@@ -13,7 +13,7 @@
 
 <title>Contact the Vocab Team</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,9 +420,22 @@ <h1 class="title toc-ignore">Contact the Vocab Team</h1>
 </div>
 
 
-<p>Okay so you have something you would like to add to the CDM but there is not an existing OMOP vocabulary nor an open-source vocabulary we can bring in to support it. <strong>In this case, please contact the vocabulary team on next steps</strong> as data elements in the CDM must have a vocabulary in place before they can be implemented.</p>
-<p><a href="https://teams.microsoft.com/l/channel/19%3a31208179438d45749ff484124e7b1e5e%40thread.tacv2/Vocabulary%2520Subgroup?groupId=a6f2c516-e568-4974-8f1e-a7bdc2f997c5&amp;tenantId=a30f0094-9120-4aab-ba4c-e5509023b2d5">Vocabulary Teams Channel</a></p>
-<p>Once you come to consensus with the vocabulary team regarding your needs, please follow the <a href="cdmRequestProcess.html">CDM Request Process</a> to begin the steps soliciting a change or addition to the model itself. Need more guidance? Consider contacting the CDM Working Group on our <a href="https://github.com/OHDSI/CommonDataModel">GitHub</a> or <a href="https://teams.microsoft.com/l/team/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/conversations?groupId=a6f2c516-e568-4974-8f1e-a7bdc2f997c5&amp;tenantId=a30f0094-9120-4aab-ba4c-e5509023b2d5">Teams Channel</a>.</p>
+<p>Okay so you have something you would like to add to the CDM but there
+is not an existing OMOP vocabulary nor an open-source vocabulary we can
+bring in to support it. <strong>In this case, please contact the
+vocabulary team on next steps</strong> as data elements in the CDM must
+have a vocabulary in place before they can be implemented.</p>
+<p><a
+href="https://teams.microsoft.com/l/channel/19%3a31208179438d45749ff484124e7b1e5e%40thread.tacv2/Vocabulary%2520Subgroup?groupId=a6f2c516-e568-4974-8f1e-a7bdc2f997c5&amp;tenantId=a30f0094-9120-4aab-ba4c-e5509023b2d5">Vocabulary
+Teams Channel</a></p>
+<p>Once you come to consensus with the vocabulary team regarding your
+needs, please follow the <a href="cdmRequestProcess.html">CDM Request
+Process</a> to begin the steps soliciting a change or addition to the
+model itself. Need more guidance? Consider contacting the CDM Working
+Group on our <a
+href="https://github.com/OHDSI/CommonDataModel">GitHub</a> or <a
+href="https://teams.microsoft.com/l/team/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/conversations?groupId=a6f2c516-e568-4974-8f1e-a7bdc2f997c5&amp;tenantId=a30f0094-9120-4aab-ba4c-e5509023b2d5">Teams
+Channel</a>.</p>
 
 
 
diff --git a/docs/contribute.html b/docs/contribute.html
index f79030aa..3d0cb39c 100644
--- a/docs/contribute.html
+++ b/docs/contribute.html
@@ -13,7 +13,7 @@
 
 <title>Ask A Question</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -494,15 +498,24 @@ <h1 class="title toc-ignore">Ask A Question</h1>
 
 <div id="check-the-forum" class="section level1">
 <h1>Check the Forum</h1>
-<p>Chances are someone else has already asked your question on the <a href="https:\forums.ohdsi.org">forum</a> and it has been answered.</p>
+<p>Chances are someone else has already asked your question on the <a
+href="https:\forums.ohdsi.org">forum</a> and it has been answered.</p>
 </div>
 <div id="check-the-issue-log" class="section level1">
 <h1>Check the Issue Log</h1>
-<p>If you think you’ve found a bug you can check to see if someone also had that same problem on our <a href="https://github.com/ohdsi/commondatamodel/issues">issue page</a> of the Common Data Model github. If you don’t see your issue feel free to open one. Try and be as specific as possible. What error message occurs? Can you provide a simple example as to why you are requesting a change to the model?</p>
+<p>If you think you’ve found a bug you can check to see if someone also
+had that same problem on our <a
+href="https://github.com/ohdsi/commondatamodel/issues">issue page</a> of
+the Common Data Model github. If you don’t see your issue feel free to
+open one. Try and be as specific as possible. What error message occurs?
+Can you provide a simple example as to why you are requesting a change
+to the model?</p>
 </div>
 <div id="join-meetings" class="section level1">
 <h1>Join meetings</h1>
-<p>Please come to meetings, ask your question and contribute to the discussion! All details can be found on our <a href="https://ohdsi.github.io/CommonDataModel/">home page</a>.</p>
+<p>Please come to meetings, ask your question and contribute to the
+discussion! All details can be found on our <a
+href="https://ohdsi.github.io/CommonDataModel/">home page</a>.</p>
 </div>
 
 
diff --git a/docs/dataModelConventions.html b/docs/dataModelConventions.html
index 9ca459dd..605b2a50 100644
--- a/docs/dataModelConventions.html
+++ b/docs/dataModelConventions.html
@@ -13,7 +13,7 @@
 
 <title>dataModelConventions.knit</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -493,13 +497,30 @@
 
 <div id="data-model-conventions" class="section level1">
 <h1><strong>Data Model Conventions</strong></h1>
-<p>There are a number of implicit and explicit conventions that have been adopted in the CDM. Developers of methods that run against the CDM need to understand these conventions.</p>
+<p>There are a number of implicit and explicit conventions that have
+been adopted in the CDM. Developers of methods that run against the CDM
+need to understand these conventions.</p>
 <div id="general" class="section level2">
 <h2><strong>General</strong></h2>
-<p>The OMOP CDM is platform-independent. Data types are defined generically using ANSI SQL data types (VARCHAR, INTEGER, FLOAT, DATE, DATETIME, CLOB). Precision is provided only for VARCHAR. It reflects the minimal required string length and can be expanded within a CDM instantiation. The CDM does not prescribe the date and datetime format. Standard queries against CDM may vary for local instantiations and date/datetime configurations.</p>
+<p>The OMOP CDM is platform-independent. Data types are defined
+generically using ANSI SQL data types (VARCHAR, INTEGER, FLOAT, DATE,
+DATETIME, CLOB). Precision is provided only for VARCHAR. It reflects the
+minimal required string length and can be expanded within a CDM
+instantiation. The CDM does not prescribe the date and datetime format.
+Standard queries against CDM may vary for local instantiations and
+date/datetime configurations.</p>
 <div id="tables" class="section level3">
 <h3>Tables</h3>
-<p>For the tables of the main domains of the CDM it is imperative that concepts used are strictly limited to the domain. For example, the CONDITION_OCCURRENCE table contains only information about conditions (diagnoses, signs, symptoms), but no information about procedures. Not all source coding schemes adhere to such rules. For example, ICD-9-CM codes, which contain mostly diagnoses of human disease, also contain information about the status of patients having received a procedure. The ICD-9-CM code V20.3 ‘Newborn health supervision’ defines a continuous procedure and is therefore stored in the PROCEDURE_OCCURRENCE table.</p>
+<p>For the tables of the main domains of the CDM it is imperative that
+concepts used are strictly limited to the domain. For example, the
+CONDITION_OCCURRENCE table contains only information about conditions
+(diagnoses, signs, symptoms), but no information about procedures. Not
+all source coding schemes adhere to such rules. For example, ICD-9-CM
+codes, which contain mostly diagnoses of human disease, also contain
+information about the status of patients having received a procedure.
+The ICD-9-CM code V20.3 ‘Newborn health supervision’ defines a
+continuous procedure and is therefore stored in the PROCEDURE_OCCURRENCE
+table.</p>
 </div>
 <div id="fields" class="section level3">
 <h3>Fields</h3>
@@ -518,23 +539,43 @@ <h3>Fields</h3>
 <tbody>
 <tr class="odd">
 <td><entity>_SOURCE_VALUE</td>
-<td>Verbatim information from the source data, typically used in ETL to map to CONCEPT_ID, and not to be used by any standard analytics. For example, CONDITION_SOURCE_VALUE = ‘787.02’ was the ICD-9 code captured as a diagnosis from the administrative claim.</td>
+<td>Verbatim information from the source data, typically used in ETL to
+map to CONCEPT_ID, and not to be used by any standard analytics. For
+example, CONDITION_SOURCE_VALUE = ‘787.02’ was the ICD-9 code captured
+as a diagnosis from the administrative claim.</td>
 </tr>
 <tr class="even">
 <td><entity>_ID</td>
-<td>Unique identifiers for key entities, which can serve as foreign keys to establish relationships across entities. For example, PERSON_ID uniquely identifies each individual. VISIT_OCCURRENCE_ID uniquely identifies a PERSON encounter at a point of care.</td>
+<td>Unique identifiers for key entities, which can serve as foreign keys
+to establish relationships across entities. For example, PERSON_ID
+uniquely identifies each individual. VISIT_OCCURRENCE_ID uniquely
+identifies a PERSON encounter at a point of care.</td>
 </tr>
 <tr class="odd">
 <td><entity>_CONCEPT_ID</td>
-<td>Foreign key into the Standardized Vocabularies (i.e. the standard_concept attribute for the corresponding term is true), which serves as the primary basis for all standardized analytics. For example, CONDITION_CONCEPT_ID = <a href="http://athena.ohdsi.org/search-terms/terms/31967">31967</a> contains the reference value for the SNOMED concept of ‘Nausea’</td>
+<td>Foreign key into the Standardized Vocabularies (i.e. the
+standard_concept attribute for the corresponding term is true), which
+serves as the primary basis for all standardized analytics. For example,
+CONDITION_CONCEPT_ID = <a
+href="http://athena.ohdsi.org/search-terms/terms/31967">31967</a>
+contains the reference value for the SNOMED concept of ‘Nausea’</td>
 </tr>
 <tr class="even">
 <td><entity>_SOURCE_CONCEPT_ID</td>
-<td>Foreign key into the Standardized Vocabularies representing the concept and terminology used in the source data, when applicable. For example, CONDITION_SOURCE_CONCEPT_ID = <a href="http://athena.ohdsi.org/search-terms/terms/45431665">45431665</a> denotes the concept of ‘Nausea’ in the Read terminology; the analogous CONDITION_CONCEPT_ID might be 31967, since SNOMED-CT is the Standardized Vocabulary for most clinical diagnoses and findings.</td>
+<td>Foreign key into the Standardized Vocabularies representing the
+concept and terminology used in the source data, when applicable. For
+example, CONDITION_SOURCE_CONCEPT_ID = <a
+href="http://athena.ohdsi.org/search-terms/terms/45431665">45431665</a>
+denotes the concept of ‘Nausea’ in the Read terminology; the analogous
+CONDITION_CONCEPT_ID might be 31967, since SNOMED-CT is the Standardized
+Vocabulary for most clinical diagnoses and findings.</td>
 </tr>
 <tr class="odd">
 <td><entity>_TYPE_CONCEPT_ID</td>
-<td>Delineates the origin of the source information, standardized within the Standardized Vocabularies. For example, DRUG_TYPE_CONCEPT_ID can allow analysts to discriminate between ‘Pharmacy dispensing’ and ‘Prescription written’</td>
+<td>Delineates the origin of the source information, standardized within
+the Standardized Vocabularies. For example, DRUG_TYPE_CONCEPT_ID can
+allow analysts to discriminate between ‘Pharmacy dispensing’ and
+‘Prescription written’</td>
 </tr>
 </tbody>
 </table>
@@ -544,87 +585,241 @@ <h3>Fields</h3>
 <h2><strong>Vocabulary</strong></h2>
 <div id="concepts" class="section level3">
 <h3>Concepts</h3>
-<p>Concepts in the Common Data Model are derived from a number of public or proprietary terminologies such as SNOMED-CT and RxNorm, or custom generated to standardize aspects of observational data. Both types of Concepts are integrated based on the following rules:</p>
+<p>Concepts in the Common Data Model are derived from a number of public
+or proprietary terminologies such as SNOMED-CT and RxNorm, or custom
+generated to standardize aspects of observational data. Both types of
+Concepts are integrated based on the following rules:</p>
 <ul>
-<li>All Concepts are maintained centrally by the CDM and Vocabularies Working Group. Additional concepts can be added, as needed, upon request by creating a <a href="https://github.com/OHDSI/Vocabulary-v5.0/issues">Github issue</a>.</li>
-<li>For all Concepts, whether they are custom generated or adopted from published terminologies, a unique numeric identifier concept_id is assigned and used as the key to link all observational data to the corresponding Concept reference data.</li>
-<li>The concept_id of a Concept is persistent, i.e. stays the same for the same Concept between releases of the Standardized Vocabularies.</li>
-<li>A descriptive name for each Concept is stored as the Concept Name as part of the CONCEPT table. Additional names and descriptions for the Concept are stored as Synonyms in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a> table.</li>
-<li>Each Concept is assigned to a Domain. For Standard Concepts, there is always a single Domain. Source Concepts can be composite or coordinated entities, and therefore can belong to more than one Domain. The domain_id field of the record contains the abbreviation of the Domain, or Domain combination. Please refer to the Standardized Vocabularies specification for details of the Domain Assignment.</li>
-<li>Concept Class designations are attributes of Concepts. Each Vocabulary has its own set of permissible Concept Classes, although the same Concept Class can be used by more than one Vocabulary. Depending on the Vocabulary, the Concept Class may categorize Concepts vertically (parallel) or horizontally (hierarchically). See the specification of each vocabulary for details.</li>
-<li>Concept Class attributes should not be confused with Classification Concepts. These are separate Concepts that have a hierarchical relationship to Standard Concepts or each other, while Concept Classes are unique Vocabulary-specific attributes for each Concept.</li>
-<li>For Concepts inherited from published terminologies, the source code is retained in the concept_code field and can be used to reference the source vocabulary.</li>
-<li>Standard Concepts (designated as ‘S’ in the standard_concept field) may appear in CDM tables in all *_concept_id fields, whereas Classification Concepts (‘C’) should not appear in the CDM data, but participate in the construction of the CONCEPT_ANCESTOR table and can be used to identify Descendants that may appear in the data. See CONCEPT_ANCESTOR table. Non-standard Concepts can only appear in *_source_concept_id fields and are not used in <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> table. Please refer to the Standardized Vocabularies specifications for details of the Standard Concept designation.</li>
-<li>The lifespan of a Concept is recorded through its valid_start_date, valid_end_date and the invalid_ reason fields. This allows Concepts to correctly reflect at which point in time were defined. Usually, Concepts get deprecated if their meaning was deemed ambiguous, a duplication of another Concept, or needed revision for scientific reason. For example, drug ingredients get updated when different salt or isomer variants enter the market. Usually, drugs taken off the market do not cause a deprecation by the terminology vendor. Since observational data are valid with respect to the time they are recorded, it is key for the Standardized Vocabularies to provide even obsolete codes and maintain their relationships to other current Concepts .</li>
-<li>Concepts without a known instantiated date are assigned valid_start_date of ‘1-Jan-1970’.</li>
-<li>Concepts that are not invalid are assigned valid_end_date of ‘31-Dec-2099’.</li>
-<li>Deprecated Concepts (with a valid_end_date before the release date of the Standardized Vocabularies) will have a value of ‘D’ (deprecated without successor) or ‘U’ (updated). The updated Concepts have a record in the CONCEPT_RELATIONSHIP table indicating their active replacement Concept.</li>
-<li>Values for concept_ids generated as part of Standardized Vocabularies will be reserved from 0 to 2,000,000,000. Above this range, concept_ids are available for local use and are guaranteed not to clash with future releases of the Standardized Vocabularies.</li>
+<li>All Concepts are maintained centrally by the CDM and Vocabularies
+Working Group. Additional concepts can be added, as needed, upon request
+by creating a <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/issues">Github
+issue</a>.</li>
+<li>For all Concepts, whether they are custom generated or adopted from
+published terminologies, a unique numeric identifier concept_id is
+assigned and used as the key to link all observational data to the
+corresponding Concept reference data.</li>
+<li>The concept_id of a Concept is persistent, i.e. stays the same for
+the same Concept between releases of the Standardized Vocabularies.</li>
+<li>A descriptive name for each Concept is stored as the Concept Name as
+part of the CONCEPT table. Additional names and descriptions for the
+Concept are stored as Synonyms in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a>
+table.</li>
+<li>Each Concept is assigned to a Domain. For Standard Concepts, there
+is always a single Domain. Source Concepts can be composite or
+coordinated entities, and therefore can belong to more than one Domain.
+The domain_id field of the record contains the abbreviation of the
+Domain, or Domain combination. Please refer to the Standardized
+Vocabularies specification for details of the Domain Assignment.</li>
+<li>Concept Class designations are attributes of Concepts. Each
+Vocabulary has its own set of permissible Concept Classes, although the
+same Concept Class can be used by more than one Vocabulary. Depending on
+the Vocabulary, the Concept Class may categorize Concepts vertically
+(parallel) or horizontally (hierarchically). See the specification of
+each vocabulary for details.</li>
+<li>Concept Class attributes should not be confused with Classification
+Concepts. These are separate Concepts that have a hierarchical
+relationship to Standard Concepts or each other, while Concept Classes
+are unique Vocabulary-specific attributes for each Concept.</li>
+<li>For Concepts inherited from published terminologies, the source code
+is retained in the concept_code field and can be used to reference the
+source vocabulary.</li>
+<li>Standard Concepts (designated as ‘S’ in the standard_concept field)
+may appear in CDM tables in all *_concept_id fields, whereas
+Classification Concepts (‘C’) should not appear in the CDM data, but
+participate in the construction of the CONCEPT_ANCESTOR table and can be
+used to identify Descendants that may appear in the data. See
+CONCEPT_ANCESTOR table. Non-standard Concepts can only appear in
+*_source_concept_id fields and are not used in <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
+table. Please refer to the Standardized Vocabularies specifications for
+details of the Standard Concept designation.</li>
+<li>The lifespan of a Concept is recorded through its valid_start_date,
+valid_end_date and the invalid_ reason fields. This allows Concepts to
+correctly reflect at which point in time were defined. Usually, Concepts
+get deprecated if their meaning was deemed ambiguous, a duplication of
+another Concept, or needed revision for scientific reason. For example,
+drug ingredients get updated when different salt or isomer variants
+enter the market. Usually, drugs taken off the market do not cause a
+deprecation by the terminology vendor. Since observational data are
+valid with respect to the time they are recorded, it is key for the
+Standardized Vocabularies to provide even obsolete codes and maintain
+their relationships to other current Concepts .</li>
+<li>Concepts without a known instantiated date are assigned
+valid_start_date of ‘1-Jan-1970’.</li>
+<li>Concepts that are not invalid are assigned valid_end_date of
+‘31-Dec-2099’.</li>
+<li>Deprecated Concepts (with a valid_end_date before the release date
+of the Standardized Vocabularies) will have a value of ‘D’ (deprecated
+without successor) or ‘U’ (updated). The updated Concepts have a record
+in the CONCEPT_RELATIONSHIP table indicating their active replacement
+Concept.</li>
+<li>Values for concept_ids generated as part of Standardized
+Vocabularies will be reserved from 0 to 2,000,000,000. Above this range,
+concept_ids are available for local use and are guaranteed not to clash
+with future releases of the Standardized Vocabularies.</li>
 </ul>
 </div>
 <div id="vocabularies" class="section level3">
 <h3>Vocabularies</h3>
 <ul>
-<li>There is one record for each Vocabulary. One Vocabulary source or vendor can issue several Vocabularies, each of them creating their own record in the VOCABULARY table. However, the choice of whether a Vocabulary contains Concepts of different Concept Classes, or when these different classes constitute separate Vocabularies cannot precisely be decided based on the definition of what constitutes a Vocabulary. For example, the ICD-9 Volume 1 and 2 codes (ICD9CM, containing predominantly conditions and some procedures and observations) and the ICD-9 Volume 3 codes (ICD9Proc, containing predominantly procedures) are realized as two different Vocabularies. On the other hand, SNOMED-CT codes of the class Condition and those of the class Procedure are part of one and the same Vocabulary. Please refer to the Standardized Vocabularies specifications for details of each Vocabulary.</li>
-<li>The vocabulary_id field contains an alphanumerical identifier, that can also be used as the abbreviation of the Vocabulary name.</li>
-<li>The record with vocabulary_id = ‘None’ is reserved to contain information regarding the current version of the Entire Standardized Vocabularies.</li>
-<li>The vocabulary_name field contains the full official name of the Vocabulary, as well as the source or vendor in parenthesis.</li>
-<li>Each Vocabulary has an entry in the CONCEPT table, which is recorded in the vocabulary_concept_id field. This is for purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by a unique Concept.</li>
+<li>There is one record for each Vocabulary. One Vocabulary source or
+vendor can issue several Vocabularies, each of them creating their own
+record in the VOCABULARY table. However, the choice of whether a
+Vocabulary contains Concepts of different Concept Classes, or when these
+different classes constitute separate Vocabularies cannot precisely be
+decided based on the definition of what constitutes a Vocabulary. For
+example, the ICD-9 Volume 1 and 2 codes (ICD9CM, containing
+predominantly conditions and some procedures and observations) and the
+ICD-9 Volume 3 codes (ICD9Proc, containing predominantly procedures) are
+realized as two different Vocabularies. On the other hand, SNOMED-CT
+codes of the class Condition and those of the class Procedure are part
+of one and the same Vocabulary. Please refer to the Standardized
+Vocabularies specifications for details of each Vocabulary.</li>
+<li>The vocabulary_id field contains an alphanumerical identifier, that
+can also be used as the abbreviation of the Vocabulary name.</li>
+<li>The record with vocabulary_id = ‘None’ is reserved to contain
+information regarding the current version of the Entire Standardized
+Vocabularies.</li>
+<li>The vocabulary_name field contains the full official name of the
+Vocabulary, as well as the source or vendor in parenthesis.</li>
+<li>Each Vocabulary has an entry in the CONCEPT table, which is recorded
+in the vocabulary_concept_id field. This is for purposes of creating a
+closed Information Model, where all entities in the OMOP CDM are covered
+by a unique Concept.</li>
 </ul>
 </div>
 <div id="domains" class="section level3">
 <h3>Domains</h3>
 <ul>
-<li>There is one record for each Domain. The domains are defined by the tables and fields in the OMOP CDM that can contain Concepts describing all the various aspects of the healthcare experience of a patient.</li>
-<li>The domain_id field contains an alphanumerical identifier, that can also be used as the abbreviation of the Domain.</li>
-<li>The domain_name field contains the unabbreviated names of the Domain.</li>
-<li>Each Domain also has an entry in the Concept table, which is recorded in the domain_concept_id field. This is for purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by unique Concept.</li>
-<li>Versions prior to v5.0.0 of the OMOP CDM did not support the notion of a Domain.</li>
+<li>There is one record for each Domain. The domains are defined by the
+tables and fields in the OMOP CDM that can contain Concepts describing
+all the various aspects of the healthcare experience of a patient.</li>
+<li>The domain_id field contains an alphanumerical identifier, that can
+also be used as the abbreviation of the Domain.</li>
+<li>The domain_name field contains the unabbreviated names of the
+Domain.</li>
+<li>Each Domain also has an entry in the Concept table, which is
+recorded in the domain_concept_id field. This is for purposes of
+creating a closed Information Model, where all entities in the OMOP CDM
+are covered by unique Concept.</li>
+<li>Versions prior to v5.0.0 of the OMOP CDM did not support the notion
+of a Domain.</li>
 </ul>
 </div>
 <div id="concept-classes" class="section level3">
 <h3>Concept Classes</h3>
 <ul>
-<li>There is one record for each Concept Class. Concept Classes are used to create additional structure to the Concepts within each Vocabulary. Some Concept Classes are unique to a Vocabulary (for example “Clinical Finding” in SNOMED), but others can be used across different Vocabularies. The separation of Concepts through Concept Classes can be semantically horizontal (each Class subsumes Concepts of the same hierarchical level, akin to sub-Vocabularies within a Vocabulary) or vertical (each Class subsumes Concepts of a certain kind, going across hierarchical levels). For example, Concept Classes in SNOMED are vertical: The classes “Procedure” and “Clinical Finding” define very granular to very generic Concepts. On the other hand, “Clinical Drug” and “Ingredient” Concept Classes define horizontal layers or strata in the RxNorm vocabulary, which all belong to the same concept of a Drug.</li>
-<li>The concept_class_id field contains an alphanumerical identifier, that can also be used as the abbreviation of the Concept Class.</li>
-<li>The concept_class_name field contains the unabbreviated names of the Concept Class.</li>
-<li>Each Concept Class also has an entry in the Concept table, which is recorded in the concept_ class_concept_id field. This is for purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by unique Concepts.</li>
+<li>There is one record for each Concept Class. Concept Classes are used
+to create additional structure to the Concepts within each Vocabulary.
+Some Concept Classes are unique to a Vocabulary (for example “Clinical
+Finding” in SNOMED), but others can be used across different
+Vocabularies. The separation of Concepts through Concept Classes can be
+semantically horizontal (each Class subsumes Concepts of the same
+hierarchical level, akin to sub-Vocabularies within a Vocabulary) or
+vertical (each Class subsumes Concepts of a certain kind, going across
+hierarchical levels). For example, Concept Classes in SNOMED are
+vertical: The classes “Procedure” and “Clinical Finding” define very
+granular to very generic Concepts. On the other hand, “Clinical Drug”
+and “Ingredient” Concept Classes define horizontal layers or strata in
+the RxNorm vocabulary, which all belong to the same concept of a
+Drug.</li>
+<li>The concept_class_id field contains an alphanumerical identifier,
+that can also be used as the abbreviation of the Concept Class.</li>
+<li>The concept_class_name field contains the unabbreviated names of the
+Concept Class.</li>
+<li>Each Concept Class also has an entry in the Concept table, which is
+recorded in the concept_ class_concept_id field. This is for purposes of
+creating a closed Information Model, where all entities in the OMOP CDM
+are covered by unique Concepts.</li>
 </ul>
 </div>
 <div id="concept-relationships" class="section level3">
 <h3>Concept Relationships</h3>
 <ul>
-<li>Relationships can generally be classified as hierarchical (parent-child) or non-hierarchical (lateral).</li>
-<li>All Relationships are directional, and each Concept Relationship is represented twice symmetrically within the CONCEPT_RELATIONSHIP table. For example, the two SNOMED concepts of ‘Acute myocardial infarction of the anterior wall’ and ‘Acute myocardial infarction’ have two Concept Relationships:
+<li>Relationships can generally be classified as hierarchical
+(parent-child) or non-hierarchical (lateral).</li>
+<li>All Relationships are directional, and each Concept Relationship is
+represented twice symmetrically within the CONCEPT_RELATIONSHIP table.
+For example, the two SNOMED concepts of ‘Acute myocardial infarction of
+the anterior wall’ and ‘Acute myocardial infarction’ have two Concept
+Relationships:
 <ul>
-<li>‘Acute myocardial infarction of the anterior wall’ ‘Is a’ ‘Acute myocardial infarction’, and</li>
-<li>‘Acute myocardial infarction’ ‘Subsumes’ ‘Acute myocardial infarction of the anterior wall’.</li>
+<li>‘Acute myocardial infarction of the anterior wall’ ‘Is a’ ‘Acute
+myocardial infarction’, and</li>
+<li>‘Acute myocardial infarction’ ‘Subsumes’ ‘Acute myocardial
+infarction of the anterior wall’.</li>
 </ul></li>
-<li>There is one record for each Concept Relationship connecting the same Concepts with the same relationship_id.</li>
-<li>Since all Concept Relationships exist with their mirror image (concept_id_1 and concept_id_2 swapped, and the relationship_id replaced by the reverse_relationship_id from the RELATIONSHIP table), it is not necessary to query for the existence of a relationship both in the concept_id_1 and concept_id_2 fields.</li>
-<li>Concept Relationships define direct relationships between Concepts. Indirect relationships through 3rd Concepts are not captured in this table. However, the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> table does this for hierachical relationships over several “generations” of direct relationships.</li>
-<li>In previous versions of the CDM, the relationship_id used to be a numerical identifier. See the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#relationship">RELATIONSHIP</a> table.</li>
+<li>There is one record for each Concept Relationship connecting the
+same Concepts with the same relationship_id.</li>
+<li>Since all Concept Relationships exist with their mirror image
+(concept_id_1 and concept_id_2 swapped, and the relationship_id replaced
+by the reverse_relationship_id from the RELATIONSHIP table), it is not
+necessary to query for the existence of a relationship both in the
+concept_id_1 and concept_id_2 fields.</li>
+<li>Concept Relationships define direct relationships between Concepts.
+Indirect relationships through 3rd Concepts are not captured in this
+table. However, the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
+table does this for hierachical relationships over several “generations”
+of direct relationships.</li>
+<li>In previous versions of the CDM, the relationship_id used to be a
+numerical identifier. See the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#relationship">RELATIONSHIP</a>
+table.</li>
 </ul>
 </div>
 <div id="relationship-table" class="section level3">
 <h3>Relationship Table</h3>
 <ul>
 <li>There is one record for each Relationship.</li>
-<li>Relationships are classified as hierarchical (parent-child) or non-hierarchical (lateral)</li>
-<li>They are used to determine which concept relationship records should be included in the computation of the CONCEPT_ANCESTOR table.</li>
-<li>The relationship_id field contains an alphanumerical identifier, that can also be used as the abbreviation of the Relationship.</li>
-<li>The relationship_name field contains the unabbreviated names of the Relationship.</li>
-<li>Relationships all exist symmetrically, i.e. in both direction. The relationship_id of the opposite Relationship is provided in the reverse_relationship_id field.</li>
-<li>Each Relationship also has an equivalent entry in the Concept table, which is recorded in the relationship_ concept_id field. This is for purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by unique Concepts.</li>
-<li>Hierarchical Relationships are used to build a hierarchical tree out of the Concepts, which is recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> table. For example, “has_ingredient” is a Relationship between Concept of the Concept Class ‘Clinical Drug’ and those of ‘Ingredient’, and all Ingredients can be classified as the “parental” hierarchical Concepts for the drug products they are part of. All ‘Is a’ Relationships are hierarchical.</li>
-<li>Relationships, also hierarchical, can be between Concepts within the same Vocabulary or those adopted from different Vocabulary sources.</li>
+<li>Relationships are classified as hierarchical (parent-child) or
+non-hierarchical (lateral)</li>
+<li>They are used to determine which concept relationship records should
+be included in the computation of the CONCEPT_ANCESTOR table.</li>
+<li>The relationship_id field contains an alphanumerical identifier,
+that can also be used as the abbreviation of the Relationship.</li>
+<li>The relationship_name field contains the unabbreviated names of the
+Relationship.</li>
+<li>Relationships all exist symmetrically, i.e. in both direction. The
+relationship_id of the opposite Relationship is provided in the
+reverse_relationship_id field.</li>
+<li>Each Relationship also has an equivalent entry in the Concept table,
+which is recorded in the relationship_ concept_id field. This is for
+purposes of creating a closed Information Model, where all entities in
+the OMOP CDM are covered by unique Concepts.</li>
+<li>Hierarchical Relationships are used to build a hierarchical tree out
+of the Concepts, which is recorded in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
+table. For example, “has_ingredient” is a Relationship between Concept
+of the Concept Class ‘Clinical Drug’ and those of ‘Ingredient’, and all
+Ingredients can be classified as the “parental” hierarchical Concepts
+for the drug products they are part of. All ‘Is a’ Relationships are
+hierarchical.</li>
+<li>Relationships, also hierarchical, can be between Concepts within the
+same Vocabulary or those adopted from different Vocabulary sources.</li>
 </ul>
 </div>
 <div id="concept-synonyms" class="section level3">
 <h3>Concept Synonyms</h3>
 <ul>
-<li>The concept_synonym_name field contains a valid Synonym of a concept, including the description in the concept_name itself. I.e. each Concept has at least one Synonym in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a> table. As an example, for a SNOMED-CT Concept, if the fully specified name is stored as the concept_name of the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept">CONCEPT</a> table, then the Preferred Term and Synonyms associated with the Concept are stored in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a> table.</li>
-<li>Only Synonyms that are active and current are stored in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a> table. Tracking synonym/description history and mapping of obsolete synonyms to current Concepts/Synonyms is out of scope for the Standard Vocabularies.</li>
+<li>The concept_synonym_name field contains a valid Synonym of a
+concept, including the description in the concept_name itself. I.e. each
+Concept has at least one Synonym in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a>
+table. As an example, for a SNOMED-CT Concept, if the fully specified
+name is stored as the concept_name of the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept">CONCEPT</a>
+table, then the Preferred Term and Synonyms associated with the Concept
+are stored in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a>
+table.</li>
+<li>Only Synonyms that are active and current are stored in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a>
+table. Tracking synonym/description history and mapping of obsolete
+synonyms to current Concepts/Synonyms is out of scope for the Standard
+Vocabularies.</li>
 <li>Currently, only English Synonyms are included.</li>
 </ul>
 </div>
@@ -632,38 +827,104 @@ <h3>Concept Synonyms</h3>
 <h3>Concept Ancestor</h3>
 <ul>
 <li>Each concept is also recorded as an ancestor of itself.</li>
-<li>Only valid and Standard Concepts participate in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> table. It is not possible to find ancestors or descendants of deprecated or Source Concepts.</li>
-<li>Usually, only Concepts of the same Domain are connected through records of the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> table, but there might be exceptions.</li>
+<li>Only valid and Standard Concepts participate in the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
+table. It is not possible to find ancestors or descendants of deprecated
+or Source Concepts.</li>
+<li>Usually, only Concepts of the same Domain are connected through
+records of the <a
+href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
+table, but there might be exceptions.</li>
 </ul>
 </div>
 <div id="source-to-concept-map" class="section level3">
 <h3>Source to Concept Map</h3>
 <ul>
-<li>This table is no longer used to distribute mapping information between source codes and Standard Concepts for the Standard Vocabularies. Instead, the CONCEPT_RELATIONSHIP table is used for this purpose, using the relationship_id=‘Maps to’.</li>
-<li>However, this table can still be used for the translation of local source codes into Standard Concepts.</li>
-<li><strong>Note:</strong> This table should not be used to translate source codes to Source Concepts. The source code of a Source Concept is captured in its concept_code field. If the source codes used in a given database do not follow correct formatting the ETL will have to perform this translation. For example, if ICD-9-CM codes are recorded without a dot the ETL will have to perform a lookup function that allows identifying the correct ICD-9-CM Source Concept (with the dot in the concept_code field).</li>
-<li>The source_concept_id, or the combination of the fields source_code and the source_vocabulary_id uniquely identifies the source information. It is the equivalent to the concept_id_1 field in the CONCEPT_RELATIONSHIP table.</li>
-<li>If there is no source_concept_id available because the source codes are local and not supported by the Standard Vocabulary, the content of the field is 0 (zero, not null) encoding an undefined concept. However, local Source Concepts are established (concept_id values above 2,000,000,000).</li>
-<li>The source_code_description contains an optional description of the source code.</li>
-<li>The target_concept_id contains the Concept the source code is mapped to. It is equivalent to the concept_id_2 in the CONCEPT_RELATIONSHIP table</li>
-<li>The target_vocabulary_id field contains the vocabulary_id of the target concept. It is a duplication of the same information in the CONCEPT record of the Target Concept.</li>
-<li>The fields valid_start_date, valid_end_date and invalid_reason are used to define the life cycle of the mapping information. Invalid mapping records should not be used for mapping information.</li>
+<li>This table is no longer used to distribute mapping information
+between source codes and Standard Concepts for the Standard
+Vocabularies. Instead, the CONCEPT_RELATIONSHIP table is used for this
+purpose, using the relationship_id=‘Maps to’.</li>
+<li>However, this table can still be used for the translation of local
+source codes into Standard Concepts.</li>
+<li><strong>Note:</strong> This table should not be used to translate
+source codes to Source Concepts. The source code of a Source Concept is
+captured in its concept_code field. If the source codes used in a given
+database do not follow correct formatting the ETL will have to perform
+this translation. For example, if ICD-9-CM codes are recorded without a
+dot the ETL will have to perform a lookup function that allows
+identifying the correct ICD-9-CM Source Concept (with the dot in the
+concept_code field).</li>
+<li>The source_concept_id, or the combination of the fields source_code
+and the source_vocabulary_id uniquely identifies the source information.
+It is the equivalent to the concept_id_1 field in the
+CONCEPT_RELATIONSHIP table.</li>
+<li>If there is no source_concept_id available because the source codes
+are local and not supported by the Standard Vocabulary, the content of
+the field is 0 (zero, not null) encoding an undefined concept. However,
+local Source Concepts are established (concept_id values above
+2,000,000,000).</li>
+<li>The source_code_description contains an optional description of the
+source code.</li>
+<li>The target_concept_id contains the Concept the source code is mapped
+to. It is equivalent to the concept_id_2 in the CONCEPT_RELATIONSHIP
+table</li>
+<li>The target_vocabulary_id field contains the vocabulary_id of the
+target concept. It is a duplication of the same information in the
+CONCEPT record of the Target Concept.</li>
+<li>The fields valid_start_date, valid_end_date and invalid_reason are
+used to define the life cycle of the mapping information. Invalid
+mapping records should not be used for mapping information.</li>
 </ul>
 </div>
 <div id="drug-strength" class="section level3">
 <h3>Drug Strength</h3>
 <ul>
-<li>The DRUG_STRENGTH table contains information for each active (non-deprecated) Standard Drug Concept.</li>
-<li>A drug which contains multiple active Ingredients will result in multiple DRUG_STRENGTH records, one for each active ingredient.</li>
-<li>Ingredient strength information is provided either as absolute amount (usually for solid formulations) or as concentration (usually for liquid formulations).</li>
-<li>If the absolute amount is provided (for example, ‘Acetaminophen 5 MG Tablet’) the amount_value and amount_unit_concept_id are used to define this content (in this case 5 and ‘MG’).</li>
-<li>If the concentration is provided (for example ‘Acetaminophen 48 MG/ML Oral Solution’) the numerator_ value in combination with the numerator_unit_concept_id and denominator_unit_concept_id are used to define this content (in this case 48, ‘MG’ and ‘ML’).</li>
-<li>In case of Quantified Clinical or Branded Drugs the denominator_value contains the total amount of the solution (not the amount of the ingredient). In all other drug concept classes the denominator amount is NULL because the concentration is always normalized to the unit of the denominator. So, a product containing 960 mg in 20 mL is provided as 48 mg/mL in the Clinical Drug and Clinical Drug Component, while as a Quantified Clinical Drug it is written as 960 mg/20 mL.</li>
-<li>If the strength is provided in % (volume or mass-percent are not distinguished) it is stored in the numerator_value/numerator_unit_concept_id field combination, with both the denominator_value and denominator_unit_concept_id set to NULL. If it is a Quantified Drug the total amount of drug is provided in the denominator_value/denominator_unit_concept_id pair. E.g., the 30 G Isoconazole 2% Topical Cream is provided as 2% / in Clinical Drug and Clinical Drug Component, and as 2% /30 G.</li>
-<li>Sometimes, one Ingredient is listed with different units within the same drug. This is very rare, and usually this happens if there are more than one Precise Ingredient. For example, ‘Penicillin G, 30 Benzathine 150000 UNT/ML / Penicillin G, Procaine 150000 MEQ/ML Injectable Suspension’ contains Penicillin G in two different forms.</li>
-<li>Sometimes, different ingredients in liquid drugs are listed with different units in the denominator_ unit_concept_id. This is usually the case if the ingredients are liquids themselves (concentration provided as mL/mL) or solid substances (mg/mg). In these cases, the general assumptions is made that the density of the drug is that of water, and one can assume 1 g = 1 mL.</li>
-<li>All Drug vocabularies containing Standard Concepts have entries in the DRUG_STRENGTH table.</li>
-<li>There is now a Concept Class for supplier information whose relationships can be found in CONCEPT_ RELATIONSHIP with a relationship_id of ‘Has supplier’ and ‘Supplier of’</li>
+<li>The DRUG_STRENGTH table contains information for each active
+(non-deprecated) Standard Drug Concept.</li>
+<li>A drug which contains multiple active Ingredients will result in
+multiple DRUG_STRENGTH records, one for each active ingredient.</li>
+<li>Ingredient strength information is provided either as absolute
+amount (usually for solid formulations) or as concentration (usually for
+liquid formulations).</li>
+<li>If the absolute amount is provided (for example, ‘Acetaminophen 5 MG
+Tablet’) the amount_value and amount_unit_concept_id are used to define
+this content (in this case 5 and ‘MG’).</li>
+<li>If the concentration is provided (for example ‘Acetaminophen 48
+MG/ML Oral Solution’) the numerator_ value in combination with the
+numerator_unit_concept_id and denominator_unit_concept_id are used to
+define this content (in this case 48, ‘MG’ and ‘ML’).</li>
+<li>In case of Quantified Clinical or Branded Drugs the
+denominator_value contains the total amount of the solution (not the
+amount of the ingredient). In all other drug concept classes the
+denominator amount is NULL because the concentration is always
+normalized to the unit of the denominator. So, a product containing 960
+mg in 20 mL is provided as 48 mg/mL in the Clinical Drug and Clinical
+Drug Component, while as a Quantified Clinical Drug it is written as 960
+mg/20 mL.</li>
+<li>If the strength is provided in % (volume or mass-percent are not
+distinguished) it is stored in the
+numerator_value/numerator_unit_concept_id field combination, with both
+the denominator_value and denominator_unit_concept_id set to NULL. If it
+is a Quantified Drug the total amount of drug is provided in the
+denominator_value/denominator_unit_concept_id pair. E.g., the 30 G
+Isoconazole 2% Topical Cream is provided as 2% / in Clinical Drug and
+Clinical Drug Component, and as 2% /30 G.</li>
+<li>Sometimes, one Ingredient is listed with different units within the
+same drug. This is very rare, and usually this happens if there are more
+than one Precise Ingredient. For example, ‘Penicillin G, 30 Benzathine
+150000 UNT/ML / Penicillin G, Procaine 150000 MEQ/ML Injectable
+Suspension’ contains Penicillin G in two different forms.</li>
+<li>Sometimes, different ingredients in liquid drugs are listed with
+different units in the denominator_ unit_concept_id. This is usually the
+case if the ingredients are liquids themselves (concentration provided
+as mL/mL) or solid substances (mg/mg). In these cases, the general
+assumptions is made that the density of the drug is that of water, and
+one can assume 1 g = 1 mL.</li>
+<li>All Drug vocabularies containing Standard Concepts have entries in
+the DRUG_STRENGTH table.</li>
+<li>There is now a Concept Class for supplier information whose
+relationships can be found in CONCEPT_ RELATIONSHIP with a
+relationship_id of ‘Has supplier’ and ‘Supplier of’</li>
 </ul>
 </div>
 </div>
@@ -671,28 +932,80 @@ <h3>Drug Strength</h3>
 <h2><strong>Mapping</strong></h2>
 <div id="representing-content-as-concepts" class="section level3">
 <h3>Representing content as Concepts</h3>
-<p>In CDM data tables the meaning of the content of each record is represented using Concepts. Concepts are stored with their CONCEPT_ID as foreign keys to the CONCEPT table in the Standardized Vocabularies, which contains Concepts necessary to describe the healthcare experience of a patient. If a Standard Concept does not exist or cannot be identified, the Concept with the CONCEPT_ID 0 is used, representing a non-existing or un-mappable concept.</p>
-<p>Records in the CONCEPT table contain all the detailed information about it (name, domain, class etc.). Concepts, Concept Relationships and other information relating to Concepts is contained in the tables of the Standardized Vocabularies.</p>
+<p>In CDM data tables the meaning of the content of each record is
+represented using Concepts. Concepts are stored with their CONCEPT_ID as
+foreign keys to the CONCEPT table in the Standardized Vocabularies,
+which contains Concepts necessary to describe the healthcare experience
+of a patient. If a Standard Concept does not exist or cannot be
+identified, the Concept with the CONCEPT_ID 0 is used, representing a
+non-existing or un-mappable concept.</p>
+<p>Records in the CONCEPT table contain all the detailed information
+about it (name, domain, class etc.). Concepts, Concept Relationships and
+other information relating to Concepts is contained in the tables of the
+Standardized Vocabularies.</p>
 </div>
 <div id="concept-ids-and-source-values" class="section level3">
 <h3>Concept IDs and Source Values</h3>
-<p>Many tables contain equivalent information multiple times: As a Source Value, a Source Concept and as a Standard Concept.</p>
+<p>Many tables contain equivalent information multiple times: As a
+Source Value, a Source Concept and as a Standard Concept.</p>
 <ul>
-<li>Source Values contain the codes from public code systems such as ICD-9-CM, NDC, CPT-4 etc. or locally controlled vocabularies (such as F for female and M for male) copied from the source data. Source Values are stored in the *_SOURCE_VALUE fields in the data tables.</li>
-<li>Concepts are CDM-specific entities that represent the meaning of a clinical fact. Most concepts are based on code systems used in healthcare (called Source Concepts), while others were created de-novo (CONCEPT_CODE = ‘OMOP generated’). Concepts have unique IDs across all domains.</li>
-<li>Source Concepts are the concepts that represent the code used in the source. Source Concepts are only used for common healthcare code systems, not for OMOP-generated Concepts. Source Concepts are stored in the *_SOURCE_CONCEPT_ID field in the data tables.</li>
-<li>Standard Concepts are those concepts that are used to define the unique meaning of a clinical entity. For each entity there is one Standard Concept. Standard Concepts are typically drawn from existing public vocabulary sources. Concepts that have the equivalent meaning to a Standard Concept are mapped to the Standard Concept. Standard Concepts are referred to in the <entity>_CONCEPT_ID field of the data tables.</li>
+<li>Source Values contain the codes from public code systems such as
+ICD-9-CM, NDC, CPT-4 etc. or locally controlled vocabularies (such as F
+for female and M for male) copied from the source data. Source Values
+are stored in the *_SOURCE_VALUE fields in the data tables.</li>
+<li>Concepts are CDM-specific entities that represent the meaning of a
+clinical fact. Most concepts are based on code systems used in
+healthcare (called Source Concepts), while others were created de-novo
+(CONCEPT_CODE = ‘OMOP generated’). Concepts have unique IDs across all
+domains.</li>
+<li>Source Concepts are the concepts that represent the code used in the
+source. Source Concepts are only used for common healthcare code
+systems, not for OMOP-generated Concepts. Source Concepts are stored in
+the *_SOURCE_CONCEPT_ID field in the data tables.</li>
+<li>Standard Concepts are those concepts that are used to define the
+unique meaning of a clinical entity. For each entity there is one
+Standard Concept. Standard Concepts are typically drawn from existing
+public vocabulary sources. Concepts that have the equivalent meaning to
+a Standard Concept are mapped to the Standard Concept. Standard Concepts
+are referred to in the <entity>_CONCEPT_ID field of the data
+tables.</li>
 </ul>
-<p>Source Values are only provided for convenience and quality assurance (QA) purposes. Source Values and Source Concepts are optional, while Standard Concepts are mandatory. Source Values may contain information that is only meaningful in the context of a specific data source.</p>
+<p>Source Values are only provided for convenience and quality assurance
+(QA) purposes. Source Values and Source Concepts are optional, while
+Standard Concepts are mandatory. Source Values may contain information
+that is only meaningful in the context of a specific data source.</p>
 </div>
 <div id="type-concepts" class="section level3">
 <h3>Type Concepts</h3>
 <p><em>By Mik Kallfelz and Dmitry Dymshyts</em></p>
-<p>Type Concepts (ending in _TYPE_CONCEPT_ID) are present in many tables. They are special Concepts with the purpose of indicating from where the data are derived in the source. For example, the Type Concept field can be used to distinguish a DRUG_EXPOSURE record that is derived from a pharmacy-dispensing claim from one indicative of a prescription written in an electronic health record (EHR).</p>
+<p>Type Concepts (ending in _TYPE_CONCEPT_ID) are present in many
+tables. They are special Concepts with the purpose of indicating from
+where the data are derived in the source. For example, the Type Concept
+field can be used to distinguish a DRUG_EXPOSURE record that is derived
+from a pharmacy-dispensing claim from one indicative of a prescription
+written in an electronic health record (EHR).</p>
 <ul>
-<li>Type concepts help determining the provenance of a record in the OMOP CDM. Many tables hold a specific _type_concept_id field for which <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">valid concepts</a> can be used to indicate a particular source of that record. For a condition it can be helpful to know, if it was derived from an EHR system or insurance claims. For a drug exposure it should be very useful to distinguish between prescriptions and actual administrations.</li>
-<li>In respect to the target table, matching type concepts should be chosen during the ETL step while processing sources. There are various representations in the list of type concepts of which some are quite specific for one table and others can be applied for many tables / domains, as they are quite generic. There is however no plausibility check or dependency between type concepts and tables which means they have to be chosen correctly.</li>
-<li>There is now one specific <a href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary</a> for type concepts which replaced a number of previously existing tables. For example, where previously there was a dedicated vocabulary for Drug Type Concepts, now we would choose the respective ones from the overall vocabulary (and ignore some of the old ones):</li>
+<li>Type concepts help determining the provenance of a record in the
+OMOP CDM. Many tables hold a specific _type_concept_id field for which
+<a
+href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">valid
+concepts</a> can be used to indicate a particular source of that record.
+For a condition it can be helpful to know, if it was derived from an EHR
+system or insurance claims. For a drug exposure it should be very useful
+to distinguish between prescriptions and actual administrations.</li>
+<li>In respect to the target table, matching type concepts should be
+chosen during the ETL step while processing sources. There are various
+representations in the list of type concepts of which some are quite
+specific for one table and others can be applied for many tables /
+domains, as they are quite generic. There is however no plausibility
+check or dependency between type concepts and tables which means they
+have to be chosen correctly.</li>
+<li>There is now one specific <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary</a>
+for type concepts which replaced a number of previously existing tables.
+For example, where previously there was a dedicated vocabulary for Drug
+Type Concepts, now we would choose the respective ones from the overall
+vocabulary (and ignore some of the old ones):</li>
 </ul>
 <table>
 <colgroup>
@@ -779,49 +1092,141 @@ <h3>Type Concepts</h3>
 </div>
 <div id="time-span-of-available-data" class="section level3">
 <h3>Time span of available data</h3>
-<p>Data tables for clinical data contain a datetime stamp (ending in _DATETIME, _START_DATETIME or _END_DATETIME), indicating when that clinical event occurred. As a rule, no record can be outside of a valid OBSERVATION_PERIOD time period. Clinical information that relates to events that happened prior to the first OBSERVATION_PERIOD will be captured as a record in the OBSERVATION table as ‘Medical history’ (CONCEPT_ID = 43054928), with the OBSERVATION_DATETIME set to the first OBSERVATION_PERIOD_START_DATE of that patient, and the VALUE_AS_CONCEPT_ID set to the corresponding CONCEPT_ID for the condition/drug/procedure that occurred in the past. No data occurring after the last OBSERVATION_PERIOD_END_DATE can be valid records in the CDM. * When mapping source data to the CDM, if time is unknown the default time of 00:00:00 should be chosen.</p>
+<p>Data tables for clinical data contain a datetime stamp (ending in
+_DATETIME, _START_DATETIME or _END_DATETIME), indicating when that
+clinical event occurred. As a rule, no record can be outside of a valid
+OBSERVATION_PERIOD time period. Clinical information that relates to
+events that happened prior to the first OBSERVATION_PERIOD will be
+captured as a record in the OBSERVATION table as ‘Medical history’
+(CONCEPT_ID = 43054928), with the OBSERVATION_DATETIME set to the first
+OBSERVATION_PERIOD_START_DATE of that patient, and the
+VALUE_AS_CONCEPT_ID set to the corresponding CONCEPT_ID for the
+condition/drug/procedure that occurred in the past. No data occurring
+after the last OBSERVATION_PERIOD_END_DATE can be valid records in the
+CDM. * When mapping source data to the CDM, if time is unknown the
+default time of 00:00:00 should be chosen.</p>
 </div>
-<div id="source-values-source-concept-ids-and-standard-concept-ids" class="section level3">
+<div id="source-values-source-concept-ids-and-standard-concept-ids"
+class="section level3">
 <h3>Source Values, Source Concept Ids, and Standard Concept Ids</h3>
-<p>Each table contains fields for Source Values, Source Concept Ids, and Standard Concept Ids.</p>
+<p>Each table contains fields for Source Values, Source Concept Ids, and
+Standard Concept Ids.</p>
 <ul>
-<li>Source Values are fields to maintain the verbatim information from the source database, stored as unstructured text, and are generally not to be used by any standardized analytics. There is no standardization for these fields and these columns can be used as the local CDM builders see fit. A typical example would be an ICD-9 code without the decimal from an administrative claim as condition_source_value = ‘78702’ which is how it appeared in the source.</li>
-<li>Source Concept Ids provide a repeatable representation of the source concept, when the source data are drawn from a commonly-used, internationally-recognized vocabulary that has been distributed with the OMOP Common Data Model. Specific use cases where source vocabulary-specific analytics are required can be accommodated by the use of the *_SOURCE_CONCEPT_ID fields, but these are generally not applicable across disparate data sources. The standard *_CONCEPT_ID fields are <strong>strongly suggested</strong> to be used in all standardized analytics, as specific vocabularies have been established within each data domain to facilitate standardization of both structure and content within the OMOP Common Data Model.</li>
+<li>Source Values are fields to maintain the verbatim information from
+the source database, stored as unstructured text, and are generally not
+to be used by any standardized analytics. There is no standardization
+for these fields and these columns can be used as the local CDM builders
+see fit. A typical example would be an ICD-9 code without the decimal
+from an administrative claim as condition_source_value = ‘78702’ which
+is how it appeared in the source.</li>
+<li>Source Concept Ids provide a repeatable representation of the source
+concept, when the source data are drawn from a commonly-used,
+internationally-recognized vocabulary that has been distributed with the
+OMOP Common Data Model. Specific use cases where source
+vocabulary-specific analytics are required can be accommodated by the
+use of the *_SOURCE_CONCEPT_ID fields, but these are generally not
+applicable across disparate data sources. The standard *_CONCEPT_ID
+fields are <strong>strongly suggested</strong> to be used in all
+standardized analytics, as specific vocabularies have been established
+within each data domain to facilitate standardization of both structure
+and content within the OMOP Common Data Model.</li>
 </ul>
-<p>The following provide conventions for processing source data using these three fields in each domain:</p>
-<p>When processing data where the source value is either free text or a reference to a coding scheme that is not contained within the Standardized Vocabularies:</p>
+<p>The following provide conventions for processing source data using
+these three fields in each domain:</p>
+<p>When processing data where the source value is either free text or a
+reference to a coding scheme that is not contained within the
+Standardized Vocabularies:</p>
 <ul>
-<li>Map all Source Values to the corresponding Standard CONCEPT_IDs. Store the CONCEPT_IDs in the TARGET_CONCEPT_ID field of the SOURCE_TO_CONCEPT_MAP table.
+<li>Map all Source Values to the corresponding Standard CONCEPT_IDs.
+Store the CONCEPT_IDs in the TARGET_CONCEPT_ID field of the
+SOURCE_TO_CONCEPT_MAP table.
 <ul>
-<li>If a CONCEPT_ID is not available for the source code, the TARGET_CONCEPT_ID field is set to 0.</li>
+<li>If a CONCEPT_ID is not available for the source code, the
+TARGET_CONCEPT_ID field is set to 0.</li>
 </ul></li>
 </ul>
-<p>When processing your data where Source Value is a reference to a coding scheme contained within the Standardized Vocabularies:</p>
+<p>When processing your data where Source Value is a reference to a
+coding scheme contained within the Standardized Vocabularies:</p>
 <ul>
-<li>Find all CONCEPT_IDs in the Source Vocabulary that correspond to your Source Values. Store the result in the SOURCE_CONCEPT_ID field.
+<li>Find all CONCEPT_IDs in the Source Vocabulary that correspond to
+your Source Values. Store the result in the SOURCE_CONCEPT_ID field.
 <ul>
-<li>If the source code follows the same formatting as the distributed vocabulary, the mapping can be directly obtained from the CONCEPT table using the CONCEPT_CODE field.</li>
-<li>If the source code uses alternative formatting (ex. format has removed decimal point from ICD-9 codes), you will need to perform the formatting transformation within the ETL. In this case, you may wish to store the mappings from original codes to SOURCE_CONCEPT_IDs in the SOURCE_TO_CONCEPT_MAP table.</li>
-<li>If the source code is not found in a vocabulary, the SOURCE_CONCEPT_ID field is set to 0</li>
+<li>If the source code follows the same formatting as the distributed
+vocabulary, the mapping can be directly obtained from the CONCEPT table
+using the CONCEPT_CODE field.</li>
+<li>If the source code uses alternative formatting (ex. format has
+removed decimal point from ICD-9 codes), you will need to perform the
+formatting transformation within the ETL. In this case, you may wish to
+store the mappings from original codes to SOURCE_CONCEPT_IDs in the
+SOURCE_TO_CONCEPT_MAP table.</li>
+<li>If the source code is not found in a vocabulary, the
+SOURCE_CONCEPT_ID field is set to 0</li>
 </ul></li>
-<li>Use the CONCEPT_RELATIONSHIP table to identify the Standard CONCEPT_ID that corresponds to the SOURCE_CONCEPT_ID in the domain.
+<li>Use the CONCEPT_RELATIONSHIP table to identify the Standard
+CONCEPT_ID that corresponds to the SOURCE_CONCEPT_ID in the domain.
 <ul>
-<li>Each SOURCE_CONCEPT_ID can have 1 or more Standard CONCEPT_IDs mapped to it. Each Standard CONCEPT_ID belongs to only one primary domain but when a source CONCEPT_ID maps to multiple Standard CONCEPT_IDs, it is possible for that SOURCE_CONCEPT_ID to result in records being produced across multiple domains. For example, ICD-10-CM code Z34.00 ‘Encounter for supervision of normal first pregnancy, unspecified trimester’ will be mapped to the SNOMED concept ‘Routine antenatal care’ in the procedure domain and the concept in the condition domain ‘Primagravida’. It is also possible for one SOURCE_CONCEPT_ID to map to multiple Standard CONCEPT_IDs within the same domain. For example, ICD-9-CM code 070.43 ‘Hepatitis E with hepatic coma’ maps to the SNOMED concept for ‘Acute hepatitis E’ and a second SNOMED concept for ‘Hepatic coma’, in which case multiple CONDITION_OCCURRENCE records will be generated for the one source value record.</li>
-<li>If the SOURCE_CONCEPT_ID is not mappable to any Standard CONCEPT_ID, the <entity>_CONCEPT_ID field is set to 0.</li>
+<li>Each SOURCE_CONCEPT_ID can have 1 or more Standard CONCEPT_IDs
+mapped to it. Each Standard CONCEPT_ID belongs to only one primary
+domain but when a source CONCEPT_ID maps to multiple Standard
+CONCEPT_IDs, it is possible for that SOURCE_CONCEPT_ID to result in
+records being produced across multiple domains. For example, ICD-10-CM
+code Z34.00 ‘Encounter for supervision of normal first pregnancy,
+unspecified trimester’ will be mapped to the SNOMED concept ‘Routine
+antenatal care’ in the procedure domain and the concept in the condition
+domain ‘Primagravida’. It is also possible for one SOURCE_CONCEPT_ID to
+map to multiple Standard CONCEPT_IDs within the same domain. For
+example, ICD-9-CM code 070.43 ‘Hepatitis E with hepatic coma’ maps to
+the SNOMED concept for ‘Acute hepatitis E’ and a second SNOMED concept
+for ‘Hepatic coma’, in which case multiple CONDITION_OCCURRENCE records
+will be generated for the one source value record.</li>
+<li>If the SOURCE_CONCEPT_ID is not mappable to any Standard CONCEPT_ID,
+the <entity>_CONCEPT_ID field is set to 0.</li>
 </ul></li>
-<li>Write the data record into the table(s) corresponding to the domain of the Standard CONCEPT_ID(s).
+<li>Write the data record into the table(s) corresponding to the domain
+of the Standard CONCEPT_ID(s).
 <ul>
-<li>If the Source Value has a SOURCE_CONCEPT_ID but the SOURCE_CONCEPT_ID is not mapped to a Standard CONCEPT_ID, then the domain for the data record, and hence it’s table location, is determined by the DOMAIN_ID field of the CONCEPT record the SOURCE_CONCEPT_ID refers to. The Standard <entity>_CONCEPT_ID is set to 0.</li>
-<li>If the Source Value cannot be mapped to a SOURCE_CONCEPT_ID or Standard CONCEPT_ID, then direct the data record to the most appropriate CDM domain based on your local knowledge of the intent of the source data and associated value. For example, if the un-mappable Source Value came from a ‘diagnosis’ table then, in the absence of other information, you may choose to record that fact in the CONDITION_OCCURRENCE table.</li>
+<li>If the Source Value has a SOURCE_CONCEPT_ID but the
+SOURCE_CONCEPT_ID is not mapped to a Standard CONCEPT_ID, then the
+domain for the data record, and hence it’s table location, is determined
+by the DOMAIN_ID field of the CONCEPT record the SOURCE_CONCEPT_ID
+refers to. The Standard <entity>_CONCEPT_ID is set to 0.</li>
+<li>If the Source Value cannot be mapped to a SOURCE_CONCEPT_ID or
+Standard CONCEPT_ID, then direct the data record to the most appropriate
+CDM domain based on your local knowledge of the intent of the source
+data and associated value. For example, if the un-mappable Source Value
+came from a ‘diagnosis’ table then, in the absence of other information,
+you may choose to record that fact in the CONDITION_OCCURRENCE
+table.</li>
 </ul></li>
 </ul>
-<p>Each Standard CONCEPT_ID field has a set of allowable CONCEPT_ID values. The allowable values are defined by the domain of the concepts. For example, there is a domain concept of ‘Gender’, for which there are only two allowable standard concepts of practical use (8507 - ‘Male’, 8532- ‘Female’) and one allowable generic concept to represent a standard notion of ‘no information’ (concept_id = 0). This ‘no information’ concept should be used when there is no mapping to a standard concept available or if there is no information available for that field. The exceptions are MEASUREMENT.VALUE_AS_CONCEPT_ID, OBSERVATION.VALUE_AS_CONCEPT_ID, MEASUREMENT.UNIT_CONCEPT_ID, OBSERVATION.UNIT_CONCEPT_ID, MEASUREMENT.OPERATOR_CONCEPT_ID, and OBSERVATION.MODIFIER_CONCEPT_ID, which can be NULL if the data do not contain the information (<a href="https://github.com/OHDSI/Themis/issues/11">THEMIS issue #11</a>).</p>
-<p>There is no constraint on allowed CONCEPT_IDs within the SOURCE_CONCEPT_ID fields.</p>
+<p>Each Standard CONCEPT_ID field has a set of allowable CONCEPT_ID
+values. The allowable values are defined by the domain of the concepts.
+For example, there is a domain concept of ‘Gender’, for which there are
+only two allowable standard concepts of practical use (8507 - ‘Male’,
+8532- ‘Female’) and one allowable generic concept to represent a
+standard notion of ‘no information’ (concept_id = 0). This ‘no
+information’ concept should be used when there is no mapping to a
+standard concept available or if there is no information available for
+that field. The exceptions are MEASUREMENT.VALUE_AS_CONCEPT_ID,
+OBSERVATION.VALUE_AS_CONCEPT_ID, MEASUREMENT.UNIT_CONCEPT_ID,
+OBSERVATION.UNIT_CONCEPT_ID, MEASUREMENT.OPERATOR_CONCEPT_ID, and
+OBSERVATION.MODIFIER_CONCEPT_ID, which can be NULL if the data do not
+contain the information (<a
+href="https://github.com/OHDSI/Themis/issues/11">THEMIS issue
+#11</a>).</p>
+<p>There is no constraint on allowed CONCEPT_IDs within the
+SOURCE_CONCEPT_ID fields.</p>
 </div>
 <div id="custom-source_to_concept_map" class="section level3">
 <h3>Custom SOURCE_TO_CONCEPT_MAP</h3>
-<p>When the source data uses coding systems that are not currently in the Standardized Vocabularies (e.g. ICPC codes for diagnoses), the convention is to store the mapping of such source codes to Standard Concepts in the SOURCE_TO_CONCEPT_MAP table. The codes used in the data source can be recorded in the SOURCE_VALUE fields, but no SOURCE_CONCEPT_ID will be available.</p>
-<p>Custom source codes are not allowed to map to Standard Concepts that are marked as invalid.</p>
+<p>When the source data uses coding systems that are not currently in
+the Standardized Vocabularies (e.g. ICPC codes for diagnoses), the
+convention is to store the mapping of such source codes to Standard
+Concepts in the SOURCE_TO_CONCEPT_MAP table. The codes used in the data
+source can be recorded in the SOURCE_VALUE fields, but no
+SOURCE_CONCEPT_ID will be available.</p>
+<p>Custom source codes are not allowed to map to Standard Concepts that
+are marked as invalid.</p>
 </div>
 </div>
 </div>
diff --git a/docs/download.html b/docs/download.html
index 5d9c5c70..190cf40a 100644
--- a/docs/download.html
+++ b/docs/download.html
@@ -13,7 +13,7 @@
 
 <title>Download</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -492,8 +496,22 @@ <h1 class="title toc-ignore">Download</h1>
 </div>
 
 
-<p>All code for the ddls, constraints and indices are available on our <a href="https://github.com/OHDSI/CommonDataModel">github</a>. Each version of the Common Data Model is denoted by a <a href="https://github.com/OHDSI/CommonDataModel/tags">release</a>. The OHDSI community supports the database management systems (dbms) Sql Server, Postgresql, Oracle, Redshift, Parallel Data Warehouse, BigQuery, Impala, and Netezza. Included in each release is a folder for each dbms. After downloading, choose the folder for your specific system and you will see all necessary files. For example the Sql Server folder has the ddl, primary key constraints, indices, and foreign key constraints. In contrast, the redshift folder only has a ddl.</p>
-<p>These sql scripts have been fully tested on Oracle, Sql Server, and Postgresql and the rest are generated using the <a href="https://ohdsi.github.io/SqlRender/">SqlRender package</a>. If run into any problems please let us know by creating an issue on our github.</p>
+<p>All code for the ddls, constraints and indices are available on our
+<a href="https://github.com/OHDSI/CommonDataModel">github</a>. Each
+version of the Common Data Model is denoted by a <a
+href="https://github.com/OHDSI/CommonDataModel/tags">release</a>. The
+OHDSI community supports the database management systems (dbms) Sql
+Server, Postgresql, Oracle, Redshift, Parallel Data Warehouse, BigQuery,
+Impala, and Netezza. Included in each release is a folder for each dbms.
+After downloading, choose the folder for your specific system and you
+will see all necessary files. For example the Sql Server folder has the
+ddl, primary key constraints, indices, and foreign key constraints. In
+contrast, the redshift folder only has a ddl.</p>
+<p>These sql scripts have been fully tested on Oracle, Sql Server, and
+Postgresql and the rest are generated using the <a
+href="https://ohdsi.github.io/SqlRender/">SqlRender package</a>. If run
+into any problems please let us know by creating an issue on our
+github.</p>
 
 
 
diff --git a/docs/drug_dose.html b/docs/drug_dose.html
index cb458f60..8f4bdd36 100644
--- a/docs/drug_dose.html
+++ b/docs/drug_dose.html
@@ -15,7 +15,7 @@
 
 <title>drug_dose.knit</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -147,11 +147,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -253,7 +257,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -419,9 +423,84 @@
 
 <div id="how-to-calculate-drug-dose" class="section level1">
 <h1><strong>How to Calculate Drug Dose</strong></h1>
-<p>These conventions have been curated to show how to consider calculating cumulative and daily drug dose for a given exposure record. These are high-level examples meant to demonstrate how one might use the DRUG_STRENGTH table and they do not take into account switching or stockpiling.</p>
-<p><strong>1. Tablets and other fixed amount formulations</strong><br><br> <strong>Example</strong>: Acetaminophen (Paracetamol) 500 mg, 20 tablets.<br> <strong>DRUG_STRENGTH</strong> The denominator_unit is empty<br> <strong>DRUG_EXPOSURE</strong> The quantity refers to number of pieces, e.g. tablets.<br> <em>In the example</em>: 20<br> <code>Ingredient dose= quantity x amount_value [amount_unit_concept_id]</code><br> Acetaminophen dose = 20 x 500mg = 10,000mg<br> Daily dose = Acetaminophen dose/drug duration<br><br></p>
-<p><strong>2. Puffs of an inhaler</strong><br><br> <strong>Note</strong>: There is no difference to use case 1 above besides that the DRUG_STRENGTH table may put {actuat} in the denominator unit. In this case the strength is provided in the numerator.<br> <strong>DRUG_STRENGTH</strong> The denominator_unit is {actuat}<br> <strong>DRUG_EXPOSURE</strong> The quantity refers to the number of pieces, e.g. puffs<br> <code>Ingredient dose= quantity x numerator_value [numerator_unit_concept_id]</code><br> Daily dose = Ingredient dose/drug duration<br><br> <strong>3. Quantified Drugs which are formulated as a concentration</strong><br><br> <strong>Example</strong>: The Clinical Drug is Acetaminophen 250 mg/mL in a 5mL oral suspension. The Quantified Clinical Drug would have 1250 mg / 5 ml in the DRUG_STRENGTH table. Two suspensions are dispensed.<br> <strong>DRUG_STRENGTH</strong> The denominator_unit is either mg or mL. The denominator_value might be different from 1.<br> <strong>DRUG_EXPOSURE</strong> The quantity refers to a fraction or multiple of the pack.<br> <em>In the example</em>: 2<br> <code>Ingredient dose= quantity x numerator_value [numerator_unit_concept_id]</code><br> <em>Acetaminophen dose</em> = 2 x 1250mg = 2500mg<br> Daily dose = Acetaminophen dose/drug duration<br><br> <strong>4. Drugs with the total amount provided in quantity, e.g. chemotherapeutics</strong><br><br> <strong>Example</strong>: 42799258 “Benzyl Alcohol 0.1 ML/ML / Pramoxine hydrochloride 0.01 MG/MG Topical Gel” dispensed in a 1.25oz pack.<br> <strong>DRUG_STRENGTH</strong> The denominator_unit is either mg or mL.<br> <strong>Example</strong>: Benzyl Alcohol in mL and Pramoxine hydrochloride in mg<br> <strong>DRUG_EXPOSURE</strong> The quantity refers to mL or g.<br> <strong>Example</strong>: 1.25 x 30 <em>(conversion factor oz -&gt; mL)</em> = 37<br> <code>Ingredient dose= quantity x numerator_value [numerator_unit_concept_id]</code><br> <em>Benzyl Alcohol dose</em> = 37 x 0.1mL = 3.7mL<br> Daily dose = Benzyl Alcohol dose/drug duration<br> <em>Pramoxine hydrochloride dose</em> = 37 x 0.01mg x 1000 = 370mg<br> Daily dose = Pramoxine hydrochloride dose/drug duration<br><br> <strong>Note</strong>: The analytical side should check the denominator in the DRUG_STRENGTH table. As mg is used for the second ingredient the factor 1000 will be applied to convert between g and mg.<br><br> <strong>5. Compounded drugs</strong><br><br> <strong>Example</strong>: Ibuprofen 20%/Piroxicam 1% Cream, 30ml in 5ml tubes.<br> <strong>DRUG_STRENGTH</strong> We need entries for the ingredients of Ibuprofen and Piroxicam, probably with an amount_value of 1 and a unit of mg.<br> <strong>DRUG_EXPOSURE</strong> The quantity refers to the total amount of the compound. Use one record in the DRUG_EXPOSURE table for each compound.<br> <strong>Example</strong>: 20% Ibuprofen of 30ml = 6mL, 1% Piroxicam of 30ml = 0.3mL<br> <code>Ingredient dose= Depends on the drugs involved: One of the use cases above.</code> <em>Ibuprofen dose</em> = 6 x 1mg x 1000 = 6000mg<br> Daily dose = Ibuprofen dose/drug duration<br> <em>Piroxicam dose</em> = 0.3 x 1mg x 1000 = 300mg<br> Daily dose = Piroxicam dose/drug duration<br> <strong>Note</strong>: The analytical side determines that the denominator for both ingredients in the DRUG_STRENGTH table is mg and applies the factor 1000 to convert between mL/g and mg.<br><br> <strong>6. Drugs with the active ingredient released over time, e.g. patches</strong><br><br> <strong>Example</strong>: Ethinyl Estradiol 0.000833 MG/HR / norelgestromin 0.00625 MG/HR Weekly Transdermal Patch<br> <strong>DRUG_STRENGTH</strong> The denominator units refer to hour.<br> <strong>Example</strong>: Ethinyl Estradiol 0.000833 mg/h / norelgestromin 0.00625 mg/h<br> <strong>DRUG_EXPOSURE</strong> The quantity refers to the number of pieces.<br> <strong>Example</strong>: 1 patch<br> <code>Ingredient rate= numerator_value [numerator_unit_concept_id]</code><br> <em>Ethinyl Estradiol rate</em> = 0.000833 mg/h<br> <em>norelgestromin rate</em> 0.00625 mg/h<br> <strong>Note</strong>: This can be converted to a daily dosage by multiplying it with 24. (Assuming 1 patch at a time for at least 24 hours)</p>
+<p>These conventions have been curated to show how to consider
+calculating cumulative and daily drug dose for a given exposure record.
+These are high-level examples meant to demonstrate how one might use the
+DRUG_STRENGTH table and they do not take into account switching or
+stockpiling.</p>
+<p><strong>1. Tablets and other fixed amount
+formulations</strong><br><br> <strong>Example</strong>: Acetaminophen
+(Paracetamol) 500 mg, 20 tablets.<br> <strong>DRUG_STRENGTH</strong> The
+denominator_unit is empty<br> <strong>DRUG_EXPOSURE</strong> The
+quantity refers to number of pieces, e.g. tablets.<br> <em>In the
+example</em>: 20<br>
+<code>Ingredient dose= quantity x amount_value [amount_unit_concept_id]</code><br>
+Acetaminophen dose = 20 x 500mg = 10,000mg<br> Daily dose =
+Acetaminophen dose/drug duration<br><br></p>
+<p><strong>2. Puffs of an inhaler</strong><br><br>
+<strong>Note</strong>: There is no difference to use case 1 above
+besides that the DRUG_STRENGTH table may put {actuat} in the denominator
+unit. In this case the strength is provided in the numerator.<br>
+<strong>DRUG_STRENGTH</strong> The denominator_unit is {actuat}<br>
+<strong>DRUG_EXPOSURE</strong> The quantity refers to the number of
+pieces, e.g. puffs<br>
+<code>Ingredient dose= quantity x numerator_value [numerator_unit_concept_id]</code><br>
+Daily dose = Ingredient dose/drug duration<br><br> <strong>3. Quantified
+Drugs which are formulated as a concentration</strong><br><br>
+<strong>Example</strong>: The Clinical Drug is Acetaminophen 250 mg/mL
+in a 5mL oral suspension. The Quantified Clinical Drug would have 1250
+mg / 5 ml in the DRUG_STRENGTH table. Two suspensions are dispensed.<br>
+<strong>DRUG_STRENGTH</strong> The denominator_unit is either mg or mL.
+The denominator_value might be different from 1.<br>
+<strong>DRUG_EXPOSURE</strong> The quantity refers to a fraction or
+multiple of the pack.<br> <em>In the example</em>: 2<br>
+<code>Ingredient dose= quantity x numerator_value [numerator_unit_concept_id]</code><br>
+<em>Acetaminophen dose</em> = 2 x 1250mg = 2500mg<br> Daily dose =
+Acetaminophen dose/drug duration<br><br> <strong>4. Drugs with the total
+amount provided in quantity, e.g. chemotherapeutics</strong><br><br>
+<strong>Example</strong>: 42799258 “Benzyl Alcohol 0.1 ML/ML / Pramoxine
+hydrochloride 0.01 MG/MG Topical Gel” dispensed in a 1.25oz pack.<br>
+<strong>DRUG_STRENGTH</strong> The denominator_unit is either mg or
+mL.<br> <strong>Example</strong>: Benzyl Alcohol in mL and Pramoxine
+hydrochloride in mg<br> <strong>DRUG_EXPOSURE</strong> The quantity
+refers to mL or g.<br> <strong>Example</strong>: 1.25 x 30
+<em>(conversion factor oz -&gt; mL)</em> = 37<br>
+<code>Ingredient dose= quantity x numerator_value [numerator_unit_concept_id]</code><br>
+<em>Benzyl Alcohol dose</em> = 37 x 0.1mL = 3.7mL<br> Daily dose =
+Benzyl Alcohol dose/drug duration<br> <em>Pramoxine hydrochloride
+dose</em> = 37 x 0.01mg x 1000 = 370mg<br> Daily dose = Pramoxine
+hydrochloride dose/drug duration<br><br> <strong>Note</strong>: The
+analytical side should check the denominator in the DRUG_STRENGTH table.
+As mg is used for the second ingredient the factor 1000 will be applied
+to convert between g and mg.<br><br> <strong>5. Compounded
+drugs</strong><br><br> <strong>Example</strong>: Ibuprofen 20%/Piroxicam
+1% Cream, 30ml in 5ml tubes.<br> <strong>DRUG_STRENGTH</strong> We need
+entries for the ingredients of Ibuprofen and Piroxicam, probably with an
+amount_value of 1 and a unit of mg.<br> <strong>DRUG_EXPOSURE</strong>
+The quantity refers to the total amount of the compound. Use one record
+in the DRUG_EXPOSURE table for each compound.<br>
+<strong>Example</strong>: 20% Ibuprofen of 30ml = 6mL, 1% Piroxicam of
+30ml = 0.3mL<br>
+<code>Ingredient dose= Depends on the drugs involved: One of the use cases above.</code>
+<em>Ibuprofen dose</em> = 6 x 1mg x 1000 = 6000mg<br> Daily dose =
+Ibuprofen dose/drug duration<br> <em>Piroxicam dose</em> = 0.3 x 1mg x
+1000 = 300mg<br> Daily dose = Piroxicam dose/drug duration<br>
+<strong>Note</strong>: The analytical side determines that the
+denominator for both ingredients in the DRUG_STRENGTH table is mg and
+applies the factor 1000 to convert between mL/g and mg.<br><br>
+<strong>6. Drugs with the active ingredient released over time,
+e.g. patches</strong><br><br> <strong>Example</strong>: Ethinyl
+Estradiol 0.000833 MG/HR / norelgestromin 0.00625 MG/HR Weekly
+Transdermal Patch<br> <strong>DRUG_STRENGTH</strong> The denominator
+units refer to hour.<br> <strong>Example</strong>: Ethinyl Estradiol
+0.000833 mg/h / norelgestromin 0.00625 mg/h<br>
+<strong>DRUG_EXPOSURE</strong> The quantity refers to the number of
+pieces.<br> <strong>Example</strong>: 1 patch<br>
+<code>Ingredient rate= numerator_value [numerator_unit_concept_id]</code><br>
+<em>Ethinyl Estradiol rate</em> = 0.000833 mg/h<br> <em>norelgestromin
+rate</em> 0.00625 mg/h<br> <strong>Note</strong>: This can be converted
+to a daily dosage by multiplying it with 24. (Assuming 1 patch at a time
+for at least 24 hours)</p>
 </div>
 
 
diff --git a/docs/ehrObsPeriods.html b/docs/ehrObsPeriods.html
index eecb081a..a1603b2d 100644
--- a/docs/ehrObsPeriods.html
+++ b/docs/ehrObsPeriods.html
@@ -13,7 +13,7 @@
 
 <title>Observation Period Considerations for EHR Data</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -411,72 +415,151 @@
 
 
 
-<h1 class="title toc-ignore"><strong>Observation Period Considerations for EHR Data</strong></h1>
+<h1 class="title toc-ignore"><strong>Observation Period Considerations
+for EHR Data</strong></h1>
 
 </div>
 
 
 <p><em>By Melanie Philofsky and the EHR Working Group</em></p>
-<p>The EHR WG convened on July 24, August 7, and August 21, 2020 to discuss the creation of an Observation Period from EHR data. The current and future conventions are not prescriptive enough and leave room for various ways of interpretation. The goals of our discussions were to increase the standardization for the implementation of the OBSERVATION_PERIOD table by providing some general guidelines for determining the start, end, and gaps in Observation Periods. The suggestions we came up with are only “suggestions” at this point. More research should be done to understand how these choices might impact evidence generated using these data. All of these decisions should be tempered by local understanding of patients in the EHR you are ETLing.</p>
+<p>The EHR WG convened on July 24, August 7, and August 21, 2020 to
+discuss the creation of an Observation Period from EHR data. The current
+and future conventions are not prescriptive enough and leave room for
+various ways of interpretation. The goals of our discussions were to
+increase the standardization for the implementation of the
+OBSERVATION_PERIOD table by providing some general guidelines for
+determining the start, end, and gaps in Observation Periods. The
+suggestions we came up with are only “suggestions” at this point. More
+research should be done to understand how these choices might impact
+evidence generated using these data. All of these decisions should be
+tempered by local understanding of patients in the EHR you are
+ETLing.</p>
 <ul>
-<li><em>Note - These suggestions are not intended for HMO EHR sites since HMO EHR Observation Periods more closely resemble claims data Observation Periods.</em></li>
+<li><em>Note - These suggestions are not intended for HMO EHR sites
+since HMO EHR Observation Periods more closely resemble claims data
+Observation Periods.</em></li>
 </ul>
 <div id="observation-period-start-date" class="section level2">
 <h2>Observation Period Start Date</h2>
 <ul>
-<li>Generally an Observation Period does NOT begin before birth, however, it might begin before birth IF the pregnant mother receives care recorded in your EHR. The child’s record is then split from the mother’s record at birth but may retain care given during pregnancy. For these children in your dataset, the field <strong>observation_period_start_date should be the birth date minus 9 months</strong></li>
-<li>An <strong>Observation Period does NOT begin before the implementation of the EHR at your site</strong>. Any records prior to implementation are probably “history of” record types and not a complete EHR record of clinical events.</li>
-<li>Special consideration should be given to migration from previous EHR, implementation at different sites within your healthcare system, implementation of different modules, etc.</li>
+<li>Generally an Observation Period does NOT begin before birth,
+however, it might begin before birth IF the pregnant mother receives
+care recorded in your EHR. The child’s record is then split from the
+mother’s record at birth but may retain care given during pregnancy. For
+these children in your dataset, the field
+<strong>observation_period_start_date should be the birth date minus 9
+months</strong></li>
+<li>An <strong>Observation Period does NOT begin before the
+implementation of the EHR at your site</strong>. Any records prior to
+implementation are probably “history of” record types and not a complete
+EHR record of clinical events.</li>
+<li>Special consideration should be given to migration from previous
+EHR, implementation at different sites within your healthcare system,
+implementation of different modules, etc.</li>
 </ul>
 </div>
 <div id="observation-period-end-date" class="section level2">
 <h2>Observation Period end date</h2>
-<p>Set the <strong>observation_period_end_date</strong> as the first date from the following:</p>
+<p>Set the <strong>observation_period_end_date</strong> as the first
+date from the following:</p>
 <ul>
 <li><strong>Date of death + 60 days</strong>
 <ul>
-<li>This is a CDM convention to allow events after death (autopsy, final notes, etc).</li>
+<li>This is a CDM convention to allow events after death (autopsy, final
+notes, etc).</li>
 </ul></li>
 <li><strong>Last clinical event + 60 days</strong>
 <ul>
-<li>The assumption is that person will return to the same health provider if an adverse reaction/complication/unresolved condition occurs.</li>
+<li>The assumption is that person will return to the same health
+provider if an adverse reaction/complication/unresolved condition
+occurs.</li>
 </ul></li>
 <li><strong>Date of the data pull from the system</strong></li>
 </ul>
 </div>
-<div id="observation-period-gaps-and-persistence-windows" class="section level2">
+<div id="observation-period-gaps-and-persistence-windows"
+class="section level2">
 <h2>Observation Period Gaps and Persistence Windows</h2>
 <div id="observation-period-gaps" class="section level3">
 <h3>Observation Period Gaps</h3>
-<p>Periods of time when a Person does not receive care from your institution and therefore is not observed and should not have an Observation Period. These gaps are usually hard to determine because most Persons don’t announce their departure from an EHR/healthcare institution. Therefore, a heuristic will need to be instituted to determine Observation Period Gaps where the information is not explicit.</p>
+<p>Periods of time when a Person does not receive care from your
+institution and therefore is not observed and should not have an
+Observation Period. These gaps are usually hard to determine because
+most Persons don’t announce their departure from an EHR/healthcare
+institution. Therefore, a heuristic will need to be instituted to
+determine Observation Period Gaps where the information is not
+explicit.</p>
 </div>
 <div id="observation-period-persistence-window" class="section level3">
 <h3>Observation Period Persistence Window</h3>
-<p>Defined as the maximum time allowed between two clinical events under the assumption a Person would have a clinical event recorded, if they are not healthy and seek care.</p>
-<p><strong>Example:</strong> Person 1 has a series of clinical events recorded from <strong>Jan. 1, 2010 to June 15, 2012</strong>, where the time between clinical events does not exceed 60 days. The next clinical event for Person 1 is on <strong>Oct. 1, 2018</strong>. Starting Oct. 1, 2018 Person 1 has clinical events occurring at least every 90 days up to the present date.</p>
-<p>There is a 6+ year gap between groups of clinical events recorded in the CDM. After discussion in the EHR WG, we believe this 6+ year gap is indicative of a Person not being seen within our EHR/healthcare institution. Per convention #4 for Observation Period table, “As a general assumption, during an Observation Period any clinical event that happens to the patient is expected to be recorded. Conversely, the absence of data indicates that no clinical events occurred to the patient.” Person 1 has two Observation Periods.</p>
+<p>Defined as the maximum time allowed between two clinical events under
+the assumption a Person would have a clinical event recorded, if they
+are not healthy and seek care.</p>
+<p><strong>Example:</strong> Person 1 has a series of clinical events
+recorded from <strong>Jan. 1, 2010 to June 15, 2012</strong>, where the
+time between clinical events does not exceed 60 days. The next clinical
+event for Person 1 is on <strong>Oct. 1, 2018</strong>. Starting Oct. 1,
+2018 Person 1 has clinical events occurring at least every 90 days up to
+the present date.</p>
+<p>There is a 6+ year gap between groups of clinical events recorded in
+the CDM. After discussion in the EHR WG, we believe this 6+ year gap is
+indicative of a Person not being seen within our EHR/healthcare
+institution. Per convention #4 for Observation Period table, “As a
+general assumption, during an Observation Period any clinical event that
+happens to the patient is expected to be recorded. Conversely, the
+absence of data indicates that no clinical events occurred to the
+patient.” Person 1 has two Observation Periods.</p>
 <p><strong>1st Observation Period</strong></p>
 <ul>
 <li>observation_period_start_date = <strong>01/01/2010</strong></li>
-<li>observation_period_end_date = <strong>08/15/2012</strong> (Per the end_date guideline above)</li>
+<li>observation_period_end_date = <strong>08/15/2012</strong> (Per the
+end_date guideline above)</li>
 </ul>
 <p><strong>2nd Observation Period</strong></p>
 <ul>
 <li>observation_period_start_date = <strong>10/01/2018</strong></li>
-<li>observation_period_end_date = <strong>09/01/2020</strong> (Date of the data pull, per the end_date guideline above)</li>
+<li>observation_period_end_date = <strong>09/01/2020</strong> (Date of
+the data pull, per the end_date guideline above)</li>
 </ul>
-<p>Now, there are cases where a Person only receives care within you EHR system when absolutely necessary. And if your EHR doesn’t offer primary care services, the majority of Persons who lack healthcare insurance or any other reason why Persons are only seen in urgent or emergent situations, the above heuristic might be too restrictive. This is a guideline. A question the EHR WG debated was how long between clinical events should we assume any clinical event that happens to the Person is expected to be recorded? When should we end one Observation Period and begin another? What should be the time between events for an Observation Period Persistence Window? Wellness checkups/Visits happen approximately every 12-18 months depending on a multitude of factors.</p>
-<p><strong>Our recommendation: If Observation Period Gaps are 548 days or more, then the previous Observation Period should end and another Observation Period should begin on the date of the next clinical event as per the Person 1 example above.</strong></p>
+<p>Now, there are cases where a Person only receives care within you EHR
+system when absolutely necessary. And if your EHR doesn’t offer primary
+care services, the majority of Persons who lack healthcare insurance or
+any other reason why Persons are only seen in urgent or emergent
+situations, the above heuristic might be too restrictive. This is a
+guideline. A question the EHR WG debated was how long between clinical
+events should we assume any clinical event that happens to the Person is
+expected to be recorded? When should we end one Observation Period and
+begin another? What should be the time between events for an Observation
+Period Persistence Window? Wellness checkups/Visits happen approximately
+every 12-18 months depending on a multitude of factors.</p>
+<p><strong>Our recommendation: If Observation Period Gaps are 548 days
+or more, then the previous Observation Period should end and another
+Observation Period should begin on the date of the next clinical event
+as per the Person 1 example above.</strong></p>
 </div>
 </div>
 <div id="additional-etl-considerations" class="section level2">
 <h2>Additional ETL considerations</h2>
 <ul>
-<li>Implementation of your EHR, migration from previous EHR, implementation at different sites within your healthcare system, implementation of different modules</li>
-<li>Coverage of your healthcare system within your area, population served by the healthcare system</li>
-<li>All decisions should be tempered by local understanding of patients in the EHR you are ETLing.</li>
+<li>Implementation of your EHR, migration from previous EHR,
+implementation at different sites within your healthcare system,
+implementation of different modules</li>
+<li>Coverage of your healthcare system within your area, population
+served by the healthcare system</li>
+<li>All decisions should be tempered by local understanding of patients
+in the EHR you are ETLing.</li>
 </ul>
-<p>The Observation Period can be created by only one clinical event. However, the clinical event must NOT be from the Death table. If a Death date does not have any other clinical records 18 months before AND 18 months after the death date, then an Observation Period will not be created. We believe this logic is needed because if a Person only has a death death_date without other clinical event records, a Person is most likely not being “observed” when the death occurred. If a Person was being observed at their time of death, then other records (visit, condition, measurement, etc.) would be created. This rule is most relevant for those with death registry data since a Person who dies in the hospital has many clinical event records.</p>
+<p>The Observation Period can be created by only one clinical event.
+However, the clinical event must NOT be from the Death table. If a Death
+date does not have any other clinical records 18 months before AND 18
+months after the death date, then an Observation Period will not be
+created. We believe this logic is needed because if a Person only has a
+death death_date without other clinical event records, a Person is most
+likely not being “observed” when the death occurred. If a Person was
+being observed at their time of death, then other records (visit,
+condition, measurement, etc.) would be created. This rule is most
+relevant for those with death registry data since a Person who dies in
+the hospital has many clinical event records.</p>
 </div>
 
 
diff --git a/docs/faq.html b/docs/faq.html
index 843d41d9..79931189 100644
--- a/docs/faq.html
+++ b/docs/faq.html
@@ -13,7 +13,7 @@
 
 <title>OMOP CDM Frequently Asked Questions</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -492,107 +496,385 @@ <h1 class="title toc-ignore">OMOP CDM Frequently Asked Questions</h1>
 </div>
 
 
-<p><strong>1. I understand that the common data model (CDM) is a way of organizing disparate data sources into the same relational database design, but how can it be effective since many databases use different coding schemes?</strong></p>
-<p>During the extract, transform, load (ETL) process of converting a data source into the OMOP common data model, we standardize the structure (e.g. tables, fields, data types), conventions (e.g. rules that govern how source data should be represented), and content (e.g. what common vocabularies are used to speak the same language across clinical domains). The common data model preserves all source data, including the original source vocabulary codes, but adds the standardized vocabularies to allow for network research across the entire OHDSI research community.</p>
-<p><strong>2. How does my data get transformed into the common data model?</strong></p>
-<p>You or someone in your organization will need to create a process to build your CDM. Don’t worry though, you are not alone! The open nature of the community means that much of the code that other participants have written to transform their own data is available for you to use. If you have a data license for a large administrative claims database like IBM MarketScan® or Optum’s Clinformatics® Extended Data Mart, chances are that someone has already done the legwork. Here is one example of a full builder freely available on <a href="https://github.com/OHDSI/ETL-CDMBuilder">github</a> that has been written for a variety of data sources.</p>
-<p>The <a href="http://forums.ohdsi.org/">community forums</a> are also a great place to ask questions if you are stuck or need guidance on how to represent your data in the common data model. Members are usually very responsive!</p>
+<p><strong>1. I understand that the common data model (CDM) is a way of
+organizing disparate data sources into the same relational database
+design, but how can it be effective since many databases use different
+coding schemes?</strong></p>
+<p>During the extract, transform, load (ETL) process of converting a
+data source into the OMOP common data model, we standardize the
+structure (e.g. tables, fields, data types), conventions (e.g. rules
+that govern how source data should be represented), and content
+(e.g. what common vocabularies are used to speak the same language
+across clinical domains). The common data model preserves all source
+data, including the original source vocabulary codes, but adds the
+standardized vocabularies to allow for network research across the
+entire OHDSI research community.</p>
+<p><strong>2. How does my data get transformed into the common data
+model?</strong></p>
+<p>You or someone in your organization will need to create a process to
+build your CDM. Don’t worry though, you are not alone! The open nature
+of the community means that much of the code that other participants
+have written to transform their own data is available for you to use. If
+you have a data license for a large administrative claims database like
+IBM MarketScan® or Optum’s Clinformatics® Extended Data Mart, chances
+are that someone has already done the legwork. Here is one example of a
+full builder freely available on <a
+href="https://github.com/OHDSI/ETL-CDMBuilder">github</a> that has been
+written for a variety of data sources.</p>
+<p>The <a href="http://forums.ohdsi.org/">community forums</a> are also
+a great place to ask questions if you are stuck or need guidance on how
+to represent your data in the common data model. Members are usually
+very responsive!</p>
 <p><strong>3. Are any tables or fields optional?</strong></p>
-<p>It is expected that all tables will be present in a CDM though it is not a requirement that they are all populated. The two mandatory tables are:</p>
+<p>It is expected that all tables will be present in a CDM though it is
+not a requirement that they are all populated. The two mandatory tables
+are:</p>
 <ul>
-<li><a href="https://github.com/OHDSI/CommonDataModel/wiki/person">Person</a>: Contains records that uniquely identify each patient in the source data who is at-risk to have clinical observations recorded within the source systems.</li>
-<li><a href="https://github.com/OHDSI/CommonDataModel/wiki/observation_period">Observation_period</a>: Contains records which uniquely define the spans of time for which a Person is at-risk to have clinical events recorded within the source systems.</li>
+<li><a
+href="https://github.com/OHDSI/CommonDataModel/wiki/person">Person</a>:
+Contains records that uniquely identify each patient in the source data
+who is at-risk to have clinical observations recorded within the source
+systems.</li>
+<li><a
+href="https://github.com/OHDSI/CommonDataModel/wiki/observation_period">Observation_period</a>:
+Contains records which uniquely define the spans of time for which a
+Person is at-risk to have clinical events recorded within the source
+systems.</li>
 </ul>
-<p>It is then up to you which tables to populate, though the core event tables are generally agreed upon to be <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE">Condition_occurrence</a>, <a href="https://github.com/OHDSI/CommonDataModel/wiki/PROCEDURE_OCCURRENCE">Procedure_occurrence</a>, <a href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE">Drug_exposure</a>, <a href="https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT">Measurement</a>, and <a href="https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION">Observation</a>. Each table has certain required fields, a full list of which can be found on the Common Data Model <a href="https://github.com/OHDSI/CommonDataModel/wiki/">wiki page</a>.</p>
-<p><strong>4. Does the data model include any derived information? Which tables or values are derived?</strong></p>
-<p>The common data model stores verbatim data from the source across various clinical domains, such as records for conditions, drugs, procedures, and measurements. In addition, to assist the analyst, the common data model also provides some derived tables, based on commonly used analytic procedures. For example, the <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_ERA">Condition_era</a> table is derived from the <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURENCE">Condition_occurrence</a> table and both the <a href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_ERA">Drug_era</a> and <a href="https://github.com/OHDSI/CommonDataModel/wiki/DOSE_ERA">Dose_era</a> tables are derived from the <a href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE">Drug_exposure</a> table. An era is defined as a span of time when a patient is assumed to have a given condition or exposure to a particular active ingredient. Members of the community have written code to create these tables and it is out on the <a href="https://github.com/OHDSI/CommonDataModel/tree/master/CodeExcerpts/DerivedTables">github</a> if you choose to use it in your CDM build. It is important to reinforce, the analyst has the opportunity, but not the obligation, to use any of the derived tables and all of the source data is still available for direct use if the analysis calls for different assumptions.</p>
+<p>It is then up to you which tables to populate, though the core event
+tables are generally agreed upon to be <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE">Condition_occurrence</a>,
+<a
+href="https://github.com/OHDSI/CommonDataModel/wiki/PROCEDURE_OCCURRENCE">Procedure_occurrence</a>,
+<a
+href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE">Drug_exposure</a>,
+<a
+href="https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT">Measurement</a>,
+and <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION">Observation</a>.
+Each table has certain required fields, a full list of which can be
+found on the Common Data Model <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/">wiki page</a>.</p>
+<p><strong>4. Does the data model include any derived information? Which
+tables or values are derived?</strong></p>
+<p>The common data model stores verbatim data from the source across
+various clinical domains, such as records for conditions, drugs,
+procedures, and measurements. In addition, to assist the analyst, the
+common data model also provides some derived tables, based on commonly
+used analytic procedures. For example, the <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_ERA">Condition_era</a>
+table is derived from the <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURENCE">Condition_occurrence</a>
+table and both the <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_ERA">Drug_era</a>
+and <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/DOSE_ERA">Dose_era</a>
+tables are derived from the <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE">Drug_exposure</a>
+table. An era is defined as a span of time when a patient is assumed to
+have a given condition or exposure to a particular active ingredient.
+Members of the community have written code to create these tables and it
+is out on the <a
+href="https://github.com/OHDSI/CommonDataModel/tree/master/CodeExcerpts/DerivedTables">github</a>
+if you choose to use it in your CDM build. It is important to reinforce,
+the analyst has the opportunity, but not the obligation, to use any of
+the derived tables and all of the source data is still available for
+direct use if the analysis calls for different assumptions.</p>
 <p><strong>5. How is age captured in the model?</strong></p>
-<p>Year_of_birth, month_of_birth, day_of_birth and birth_datetime are all fields in the Person table designed to capture some form of date of birth. While only year_of_birth is required, these fields allow for maximum flexibility over a wide range of data sources.</p>
-<p><strong>6. How are gender, race, and ethnicity captured in the model? Are they coded using values a human reader can understand?</strong></p>
-<p>Standard Concepts are used to denote all clinical entities throughout the OMOP common data model, including gender, race, and ethnicity. Source values are mapped to Standard Concepts during the extract, transform, load (ETL) process of converting a database to the OMOP Common Data Model. These are then stored in the Gender_concept_id, Race_concept_id and Ethnicity_concept_id fields in the Person table. Because the standard concepts span across all clinical domains, and in keeping with Cimino’s ‘Desiderata for Controlled Medical Vocabularies in the Twenty-First Century’, the identifiers are unique, persistent nonsematic identifiers. Gender, for example, is stored as either 8532 (female) or 8507 (male) in gender_concept_id while the original value from the source is stored in gender_source_value (M, male, F, etc).</p>
-<p><strong>7. Are there conditions/procedures/drugs or other domains that should be masked or hidden in the CDM?</strong></p>
-<p>The masking of information related to a person is dependent on the organization’s privacy policies and may vary by data asset (<a href="https://github.com/OHDSI/Themis/issues/21">THEMIS issue #21</a>).</p>
-<p><strong>8. How is time-varying patient information such as location of residence addressed in the model?</strong></p>
-<p>The OMOP common data model has been pragmatically defined based on the desired analytic use cases of the community, as well as the available types of data that community members have access to. Prior to CDM v6.0, each person record had associated demographic attributes which are assumed to be constant for the patient throughout the course of their periods of observation, like location and primary care provider. With the release of CDM v6.0, the Location_History table is now available to track the movements of people, care sites, and providers over time. Only the most recent location_id should be stored in the Person table to eliminate duplication, while the person’s movements are stored in Location_History.</p>
-<p>Something like marital status is a little different as it is considered to be an observation rather than a demographic attribute. This means that it is housed in the Observation table rather than the Person table, giving the opportunity to store each change in status as a unique record.</p>
-<p>If someone in the community had a use case for time-varying location of residence and also had source data that contains this information, we’d welcome participation in the CDM workgroup to evolve the model further.</p>
-<p><strong>9. How does the model denote the time period during which a Person’s information is valid?</strong></p>
-<p>The OMOP Common Data Model uses something called observation periods (stored in the <a href="https://github.com/OHDSI/CommonDataModel/wiki/observation_period">Observation_period</a> table) as a way to define the time span during which a patient is at-risk to have a clinical event recorded. In administrative claims databases, for example, these observation periods are often analogous to the notion of ‘enrollment’.</p>
-<p><strong>10. How does the model capture start and stop dates for insurance coverage? What if a person’s coverage changes?</strong></p>
-<p>The <a href="https://github.com/OHDSI/CommonDataModel/wiki/payer_plan_period">Payer_plan_period</a> table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Payer plan periods, as opposed to observation periods, can overlap so as to denote the time when a Person is enrolled in multiple plans at the same time such as Medicare Part A and Medicare Part D.</p>
-<p><strong>11. What if I have EHR data? How would I create observation periods?</strong></p>
-<p>An observation period is considered as the time at which a patient is at-risk to have a clinical event recorded in the source system. Determining the appropriate observation period for each source data can vary, depending on what information the source contains. If a source does not provide information about a patient’s entry or exit from a system, then reasonable heuristics need to be developed and applied within the ETL.</p>
+<p>Year_of_birth, month_of_birth, day_of_birth and birth_datetime are
+all fields in the Person table designed to capture some form of date of
+birth. While only year_of_birth is required, these fields allow for
+maximum flexibility over a wide range of data sources.</p>
+<p><strong>6. How are gender, race, and ethnicity captured in the model?
+Are they coded using values a human reader can understand?</strong></p>
+<p>Standard Concepts are used to denote all clinical entities throughout
+the OMOP common data model, including gender, race, and ethnicity.
+Source values are mapped to Standard Concepts during the extract,
+transform, load (ETL) process of converting a database to the OMOP
+Common Data Model. These are then stored in the Gender_concept_id,
+Race_concept_id and Ethnicity_concept_id fields in the Person table.
+Because the standard concepts span across all clinical domains, and in
+keeping with Cimino’s ‘Desiderata for Controlled Medical Vocabularies in
+the Twenty-First Century’, the identifiers are unique, persistent
+nonsematic identifiers. Gender, for example, is stored as either 8532
+(female) or 8507 (male) in gender_concept_id while the original value
+from the source is stored in gender_source_value (M, male, F, etc).</p>
+<p><strong>7. Are there conditions/procedures/drugs or other domains
+that should be masked or hidden in the CDM?</strong></p>
+<p>The masking of information related to a person is dependent on the
+organization’s privacy policies and may vary by data asset (<a
+href="https://github.com/OHDSI/Themis/issues/21">THEMIS issue
+#21</a>).</p>
+<p><strong>8. How is time-varying patient information such as location
+of residence addressed in the model?</strong></p>
+<p>The OMOP common data model has been pragmatically defined based on
+the desired analytic use cases of the community, as well as the
+available types of data that community members have access to. Prior to
+CDM v6.0, each person record had associated demographic attributes which
+are assumed to be constant for the patient throughout the course of
+their periods of observation, like location and primary care provider.
+With the release of CDM v6.0, the Location_History table is now
+available to track the movements of people, care sites, and providers
+over time. Only the most recent location_id should be stored in the
+Person table to eliminate duplication, while the person’s movements are
+stored in Location_History.</p>
+<p>Something like marital status is a little different as it is
+considered to be an observation rather than a demographic attribute.
+This means that it is housed in the Observation table rather than the
+Person table, giving the opportunity to store each change in status as a
+unique record.</p>
+<p>If someone in the community had a use case for time-varying location
+of residence and also had source data that contains this information,
+we’d welcome participation in the CDM workgroup to evolve the model
+further.</p>
+<p><strong>9. How does the model denote the time period during which a
+Person’s information is valid?</strong></p>
+<p>The OMOP Common Data Model uses something called observation periods
+(stored in the <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/observation_period">Observation_period</a>
+table) as a way to define the time span during which a patient is
+at-risk to have a clinical event recorded. In administrative claims
+databases, for example, these observation periods are often analogous to
+the notion of ‘enrollment’.</p>
+<p><strong>10. How does the model capture start and stop dates for
+insurance coverage? What if a person’s coverage changes?</strong></p>
+<p>The <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/payer_plan_period">Payer_plan_period</a>
+table captures details of the period of time that a Person is
+continuously enrolled under a specific health Plan benefit structure
+from a given Payer. Payer plan periods, as opposed to observation
+periods, can overlap so as to denote the time when a Person is enrolled
+in multiple plans at the same time such as Medicare Part A and Medicare
+Part D.</p>
+<p><strong>11. What if I have EHR data? How would I create observation
+periods?</strong></p>
+<p>An observation period is considered as the time at which a patient is
+at-risk to have a clinical event recorded in the source system.
+Determining the appropriate observation period for each source data can
+vary, depending on what information the source contains. If a source
+does not provide information about a patient’s entry or exit from a
+system, then reasonable heuristics need to be developed and applied
+within the ETL.</p>
 <div id="vocabulary-mapping" class="section level2">
 <h2>Vocabulary Mapping</h2>
-<p><strong>12. Do I have to map my source codes to Standard Concepts myself? Are there vocabulary mappings that already exist for me to leverage?</strong></p>
-<p>If your data use any of the 55 source vocabularies that are currently supported, the mappings have been done for you. The full list is available from the open-source <a href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a> tool under the download tab (see below). You can choose to download the ten <a href="https://github.com/OHDSI/CommonDataModel/wiki/Standardized-Vocabularies">vocabulary tables</a> from there as well – you will need a copy in your environment if you plan on building a CDM.</p>
+<p><strong>12. Do I have to map my source codes to Standard Concepts
+myself? Are there vocabulary mappings that already exist for me to
+leverage?</strong></p>
+<p>If your data use any of the 55 source vocabularies that are currently
+supported, the mappings have been done for you. The full list is
+available from the open-source <a
+href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a> tool under
+the download tab (see below). You can choose to download the ten <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/Standardized-Vocabularies">vocabulary
+tables</a> from there as well – you will need a copy in your environment
+if you plan on building a CDM.</p>
 <p><img src="images/Athena_download_box.png" /></p>
-<p>The <a href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a> tool also allows you to explore the vocabulary before downloading it if you are curious about the mappings or if you have a specific code in mind and would like to know which standard concept it is associated with; just click on the search tab and type in a keyword to begin searching.</p>
-<p><strong>13. If I want to apply the mappings myself, can I do so? Are they transparent to all users?</strong></p>
-<p>Yes, all mappings are available in the <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_RELATIONSHIP">Concept_relationship</a> table (which can be downloaded from <a href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a>). Each value in a supported source terminology is assigned a Concept_id (which is considered non-standard). Each Source_concept_id will have a mapping to a Standard_concept_id. For example:</p>
+<p>The <a href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a>
+tool also allows you to explore the vocabulary before downloading it if
+you are curious about the mappings or if you have a specific code in
+mind and would like to know which standard concept it is associated
+with; just click on the search tab and type in a keyword to begin
+searching.</p>
+<p><strong>13. If I want to apply the mappings myself, can I do so? Are
+they transparent to all users?</strong></p>
+<p>Yes, all mappings are available in the <a
+href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_RELATIONSHIP">Concept_relationship</a>
+table (which can be downloaded from <a
+href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a>). Each
+value in a supported source terminology is assigned a Concept_id (which
+is considered non-standard). Each Source_concept_id will have a mapping
+to a Standard_concept_id. For example:</p>
 <p><img src="images/Sepsis_to_SNOMED.png" /></p>
-<p>In this case the standard SNOMED concept 201826 for type 2 diabetes mellitus would be stored in the Condition_occurrence table as the Condition_concept_id and the ICD10CM concept 1567956 for type 2 diabetes mellitus would be stored as the Condition_source_concept_id.</p>
-<p><strong>14. 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?</strong></p>
-<p>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.</p>
-<p><strong>15. What if the vocabulary has a mapping I don’t agree with? Can it be changed?</strong></p>
-<p>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 <a href="https://forums.ohdsi.org/">forums</a> or on the <a href="https://github.com/OHDSI/Vocabulary-v5.0/issues">vocabulary github</a>. If the community agrees with your assessment it will be addressed in the next vocabulary version.</p>
-<p><strong>16. What if I have source codes that are specific to my site? How would these be mapped?</strong></p>
-<p>In the OMOP Vocabulary there is an empty table called the Source_to_concept_map. It is a simple table structure that allows you to establish mapping(s) for each source code with a standard concept in the OMOP Vocabulary (TARGET_CONCEPT_ID). This work can be facilitated by the OHDSI tool <a href="https://github.com/OHDSI/Usagi">Usagi</a> (pictured below) which searches for text similarity between your source code descriptions and the OMOP Vocabulary and exports mappings in a SOURCE_TO_CONCEPT_MAP table structure. Example Source_to_concept_map files can be found <a href="https://github.com/OHDSI/ETL-CDMBuilder/tree/master/man/VOCABULARY_ADDITIONS">here</a>. These generated Source_to_concept_map files are then loaded into the OMOP Vocabulary’s empty Source_to_concept_map prior to processing the native data into the CDM so that the CDM builder can use them in a build.</p>
+<p>In this case the standard SNOMED concept 201826 for type 2 diabetes
+mellitus would be stored in the Condition_occurrence table as the
+Condition_concept_id and the ICD10CM concept 1567956 for type 2 diabetes
+mellitus would be stored as the Condition_source_concept_id.</p>
+<p><strong>14. 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?</strong></p>
+<p>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.</p>
+<p><strong>15. What if the vocabulary has a mapping I don’t agree with?
+Can it be changed?</strong></p>
+<p>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 <a
+href="https://forums.ohdsi.org/">forums</a> or on the <a
+href="https://github.com/OHDSI/Vocabulary-v5.0/issues">vocabulary
+github</a>. If the community agrees with your assessment it will be
+addressed in the next vocabulary version.</p>
+<p><strong>16. What if I have source codes that are specific to my site?
+How would these be mapped?</strong></p>
+<p>In the OMOP Vocabulary there is an empty table called the
+Source_to_concept_map. It is a simple table structure that allows you to
+establish mapping(s) for each source code with a standard concept in the
+OMOP Vocabulary (TARGET_CONCEPT_ID). This work can be facilitated by the
+OHDSI tool <a href="https://github.com/OHDSI/Usagi">Usagi</a> (pictured
+below) which searches for text similarity between your source code
+descriptions and the OMOP Vocabulary and exports mappings in a
+SOURCE_TO_CONCEPT_MAP table structure. Example Source_to_concept_map
+files can be found <a
+href="https://github.com/OHDSI/ETL-CDMBuilder/tree/master/man/VOCABULARY_ADDITIONS">here</a>.
+These generated Source_to_concept_map files are then loaded into the
+OMOP Vocabulary’s empty Source_to_concept_map prior to processing the
+native data into the CDM so that the CDM builder can use them in a
+build.</p>
 <p><img src="images/Usagi.png" /></p>
-<p>If an source code is not supported by the OMOP Vocabulary, one can create a new records in the CONCEPT table, however the CONCEPT_IDs should start &gt;2000000000 so that it is easy to tell between the OMOP Vocabulary concepts and the site specific concepts. Once those concepts exist CONCEPT_RELATIONSHIPS can be generated to assign them to a standard terminologies, USAGI can facilitate this process as well (<a href="https://github.com/OHDSI/Themis/issues/22">THEMIS issue #22</a>).</p>
+<p>If an source code is not supported by the OMOP Vocabulary, one can
+create a new records in the CONCEPT table, however the CONCEPT_IDs
+should start &gt;2000000000 so that it is easy to tell between the OMOP
+Vocabulary concepts and the site specific concepts. Once those concepts
+exist CONCEPT_RELATIONSHIPS can be generated to assign them to a
+standard terminologies, USAGI can facilitate this process as well (<a
+href="https://github.com/OHDSI/Themis/issues/22">THEMIS issue
+#22</a>).</p>
 <p><strong>17. How are one-to-many mappings applied?</strong></p>
-<p>If one source code maps to two Standard Concepts then two rows are stored in the corresponding clinical event table.</p>
-<p><strong>18. What if I want to keep my original data as well as the mapped values? Is there a way for me to do that?</strong></p>
-<p>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.</p>
+<p>If one source code maps to two Standard Concepts then two rows are
+stored in the corresponding clinical event table.</p>
+<p><strong>18. What if I want to keep my original data as well as the
+mapped values? Is there a way for me to do that?</strong></p>
+<p>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.</p>
 </div>
 <div id="common-data-model-versioning" class="section level2">
 <h2>Common Data Model Versioning</h2>
-<p><strong>19. Who decides when and how to change the data model?</strong></p>
-<p>The community! There is a <a href="https://docs.google.com/document/d/144e_fc7dyuinfJfbYW5MsJeSijVSzsNE7GMY6KRX10g/edit?usp=sharing">working group</a> designed around updating the model and everything is done by consensus. Members submit proposed changes to the <a href="https://github.com/OHDSI/CommonDataModel">github</a> in the form of <a href="https://github.com/OHDSI/CommonDataModel/issues">issues</a> 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.</p>
-<p><strong>20. Are changes to the model backwards compatible?</strong></p>
-<p>Generally point version changes (5.1 -&gt; 5.2) are backwards compatible and major version changes (4.0 -&gt; 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.</p>
+<p><strong>19. Who decides when and how to change the data
+model?</strong></p>
+<p>The community! There is a <a
+href="https://docs.google.com/document/d/144e_fc7dyuinfJfbYW5MsJeSijVSzsNE7GMY6KRX10g/edit?usp=sharing">working
+group</a> designed around updating the model and everything is done by
+consensus. Members submit proposed changes to the <a
+href="https://github.com/OHDSI/CommonDataModel">github</a> in the form
+of <a href="https://github.com/OHDSI/CommonDataModel/issues">issues</a>
+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.</p>
+<p><strong>20. Are changes to the model backwards
+compatible?</strong></p>
+<p>Generally point version changes (5.1 -&gt; 5.2) are backwards
+compatible and major version changes (4.0 -&gt; 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.</p>
 <p><strong>21. How frequently does the model change?</strong></p>
-<p>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.</p>
+<p>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.</p>
 <p><strong>22. What is the dissemination plan for changes?</strong></p>
-<p>Changes are first listed in the release notes on the <a href="https://github.com/OHDSI/CommonDataModel/">github</a> and in the <a href="https://github.com/OHDSI/CommonDataModel/wiki">common data model wiki</a>. New versions are also announced on the weekly community calls and on the <a href="https://forums.ohdsi.org">community forums</a>.</p>
+<p>Changes are first listed in the release notes on the <a
+href="https://github.com/OHDSI/CommonDataModel/">github</a> and in the
+<a href="https://github.com/OHDSI/CommonDataModel/wiki">common data
+model wiki</a>. New versions are also announced on the weekly community
+calls and on the <a href="https://forums.ohdsi.org">community
+forums</a>.</p>
 </div>
 <div id="ohdsi-tools" class="section level2">
 <h2>OHDSI Tools</h2>
-<p><strong>23. What are the currently available analytic tools?</strong></p>
-<p>While there are a variety of tools freely available from the community, these are the most widely used:</p>
+<p><strong>23. What are the currently available analytic
+tools?</strong></p>
+<p>While there are a variety of tools freely available from the
+community, these are the most widely used:</p>
 <ul>
-<li><a href="http://www.github.com/ohdsi/achilles">ACHILLES</a> – a stand-alone tool for database characterization</li>
-<li><a href="http://www.ohdsi.org/web/atlas/#/home">ATLAS</a> - an integrated platform for vocabulary exploration, cohort definition, case review, clinical characterization, incidence estimation, population-level effect estimation design, and patient-level prediction design (<a href="http://www.github.com/ohdsi/atlas">link to github</a>)</li>
-<li><a href="https://github.com/OHDSI/ArachneUI">ARACHNE</a> – a tool to facilitate distributed network analyses</li>
-<li><a href="https://github.com/OHDSI/whiterabbit">WhiteRabbit</a> - an application that can be used to analyse the structure and contents of a database as preparation for designing an ETL</li>
-<li><a href="https://github.com/OHDSI/whiterabbit">RabbitInAHat</a> - 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</li>
-<li><a href="https://github.com/OHDSI/usagi">Usagi</a> - an application to help create mappings between coding systems and the Vocabulary standard concepts.</li>
+<li><a href="http://www.github.com/ohdsi/achilles">ACHILLES</a> – a
+stand-alone tool for database characterization</li>
+<li><a href="http://www.ohdsi.org/web/atlas/#/home">ATLAS</a> - an
+integrated platform for vocabulary exploration, cohort definition, case
+review, clinical characterization, incidence estimation,
+population-level effect estimation design, and patient-level prediction
+design (<a href="http://www.github.com/ohdsi/atlas">link to
+github</a>)</li>
+<li><a href="https://github.com/OHDSI/ArachneUI">ARACHNE</a> – a tool to
+facilitate distributed network analyses</li>
+<li><a href="https://github.com/OHDSI/whiterabbit">WhiteRabbit</a> - an
+application that can be used to analyse the structure and contents of a
+database as preparation for designing an ETL</li>
+<li><a href="https://github.com/OHDSI/whiterabbit">RabbitInAHat</a> - 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</li>
+<li><a href="https://github.com/OHDSI/usagi">Usagi</a> - an application
+to help create mappings between coding systems and the Vocabulary
+standard concepts.</li>
 </ul>
-<p><strong>24. Who is responsible for updating the tools to account for data model changes, bugs, and errors?</strong></p>
-<p>The community! All the tools are open source meaning that anyone can submit an issue they have found, offer suggestions, and write code to fix the problem.</p>
-<p><strong>25. Do the current tools allow a user to define a treatment gap (persistence window) of any value when creating treatment episodes?</strong></p>
-<p>Yes – the ATLAS tool allows you to specify a persistence window between drug exposures when defining a cohort (see image below).</p>
+<p><strong>24. Who is responsible for updating the tools to account for
+data model changes, bugs, and errors?</strong></p>
+<p>The community! All the tools are open source meaning that anyone can
+submit an issue they have found, offer suggestions, and write code to
+fix the problem.</p>
+<p><strong>25. Do the current tools allow a user to define a treatment
+gap (persistence window) of any value when creating treatment
+episodes?</strong></p>
+<p>Yes – the ATLAS tool allows you to specify a persistence window
+between drug exposures when defining a cohort (see image below).</p>
 <p><img src="images/ATLAS_Persistence_Window.png" /></p>
-<p><strong>26. Can the current tools identify medication use during pregnancy?</strong></p>
-<p>Yes, you can identify pregnancy markers from various clinical domains, including conditions and procedures, for example ‘live birth’, and then define temporal logic to look for drug exposure records in some interval prior to the pregnancy end. In addition, members of the community have built an advanced logic to define pregnancy episodes with all pregnancy outcomes represented, which can be useful for this type of research.</p>
-<p><strong>27. Do the current tools execute against the mapped values or source values?</strong></p>
-<p>The tools can execute against both source and mapped values, though mapped values are strongly encouraged. Since one of the aims of OHDSI is to create a distributed data network across the world on which to run research studies, the use of source values fails to take advantage of the benefits of the Common Data Model.</p>
+<p><strong>26. Can the current tools identify medication use during
+pregnancy?</strong></p>
+<p>Yes, you can identify pregnancy markers from various clinical
+domains, including conditions and procedures, for example ‘live birth’,
+and then define temporal logic to look for drug exposure records in some
+interval prior to the pregnancy end. In addition, members of the
+community have built an advanced logic to define pregnancy episodes with
+all pregnancy outcomes represented, which can be useful for this type of
+research.</p>
+<p><strong>27. Do the current tools execute against the mapped values or
+source values?</strong></p>
+<p>The tools can execute against both source and mapped values, though
+mapped values are strongly encouraged. Since one of the aims of OHDSI is
+to create a distributed data network across the world on which to run
+research studies, the use of source values fails to take advantage of
+the benefits of the Common Data Model.</p>
 </div>
 <div id="network-research-studies" class="section level2">
 <h2>Network Research Studies</h2>
 <p><strong>28. Who can generate requests?</strong></p>
-<p>Anyone in the community! Any question that gains enough interest and participation can be a network research study.</p>
-<p><strong>29. Who will develop the queries to distribute to the network?</strong></p>
-<p>Typically a principal investigator leads the development of a protocol. The PI may also lead the development of the analysis procedure corresponding to the protocol. If the PI does not have the technical skills required to write the analysis procedure that implements the protocol, someone in the community can help them put it together.</p>
+<p>Anyone in the community! Any question that gains enough interest and
+participation can be a network research study.</p>
+<p><strong>29. Who will develop the queries to distribute to the
+network?</strong></p>
+<p>Typically a principal investigator leads the development of a
+protocol. The PI may also lead the development of the analysis procedure
+corresponding to the protocol. If the PI does not have the technical
+skills required to write the analysis procedure that implements the
+protocol, someone in the community can help them put it together.</p>
 <p><strong>30. What language are the queries written in?</strong></p>
-<p>Queries are written in R and SQL. The <a href="https://github.com/OHDSI/sqlrender">SqlRender</a> package can translate any query written in a templated SQL Server-like dialect to any of the supported RDBMS environments, including Postgresql, Oracle, Redshift, Parallel Data Warehouse, Hadoop Impala, Google BigQuery, and Netezza.</p>
-<p><strong>31. How do the queries get to the data partners and how are they run once there?</strong></p>
-<p>OHDSI runs as a distributed data network. All analyses are publicly available and can be downloaded to run at each site. The packages can be run locally and, at the data partner’s discretion, aggregate results can be shared with the study coordinator.</p>
-<p>Data partners can also make use of one of OHDSI’s open-source tools called <a href="https://github.com/OHDSI/arachne">ARACHNE</a>, a tool to facilitate distributed network analytics against the OMOP CDM.</p>
+<p>Queries are written in R and SQL. The <a
+href="https://github.com/OHDSI/sqlrender">SqlRender</a> package can
+translate any query written in a templated SQL Server-like dialect to
+any of the supported RDBMS environments, including Postgresql, Oracle,
+Redshift, Parallel Data Warehouse, Hadoop Impala, Google BigQuery, and
+Netezza.</p>
+<p><strong>31. How do the queries get to the data partners and how are
+they run once there?</strong></p>
+<p>OHDSI runs as a distributed data network. All analyses are publicly
+available and can be downloaded to run at each site. The packages can be
+run locally and, at the data partner’s discretion, aggregate results can
+be shared with the study coordinator.</p>
+<p>Data partners can also make use of one of OHDSI’s open-source tools
+called <a href="https://github.com/OHDSI/arachne">ARACHNE</a>, a tool to
+facilitate distributed network analytics against the OMOP CDM.</p>
 </div>
 <div id="recommended-system-requirements" class="section level2">
 <h2>Recommended System Requirements</h2>
-<p>It is difficult to recommend what technical capabilities a site needs to set up an ETL because it is heavily dependent on the amount of data they have and how they plan to use it. Here are some examples of options that have worked well for small to medium organizations and large organizations:</p>
+<p>It is difficult to recommend what technical capabilities a site needs
+to set up an ETL because it is heavily dependent on the amount of data
+they have and how they plan to use it. Here are some examples of options
+that have worked well for small to medium organizations and large
+organizations:</p>
 <p><strong>Small-to-Medium Organization</strong></p>
 <ul>
 <li>CDM size is 100MB to several GBs</li>
@@ -600,7 +882,8 @@ <h2>Recommended System Requirements</h2>
 <li>Results &lt; 500 MB</li>
 <li>Recommend
 <ul>
-<li>Server class machine disk &gt;= 250GB (SSD preferred), &gt;= 4 cores, &gt;= 32GB RAM</li>
+<li>Server class machine disk &gt;= 250GB (SSD preferred), &gt;= 4
+cores, &gt;= 32GB RAM</li>
 </ul></li>
 </ul>
 <p><strong>Large Organization</strong></p>
@@ -610,7 +893,8 @@ <h2>Recommended System Requirements</h2>
 <li>Results &lt; 500 MB</li>
 <li>Recommend
 <ul>
-<li>Cloud-based infrastructure like multiple AWS Redshift clusters, for example:</li>
+<li>Cloud-based infrastructure like multiple AWS Redshift clusters, for
+example:</li>
 <li><img src="images/AWS_clusters.png" /></li>
 </ul></li>
 </ul>
diff --git a/docs/index.html b/docs/index.html
index 6a82eae4..0a83eab2 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -475,21 +475,21 @@ <h3>Calendar</h3>
 or fill out <a
 href="https://forms.office.com/Pages/ResponsePage.aspx?id=lAAPoyCRq0q6TOVQkCOy1ZyG6Ud_r2tKuS0HcGnqiQZUOVJFUzBFWE1aSVlLN0ozR01MUVQ4T0RGNyQlQCN0PWcu">this
 form</a> and check “Common Data Model”</p>
-<div id="htmlwidget-967b972875ac12da863c_menu">
-<span id="htmlwidget-967b972875ac12da863c_menu_navi">
-<button type="button" class="btn bttn-no-outline action-button" id="htmlwidget-967b972875ac12da863c_today">Today</button>
-<button type="button" class="btn bttn-no-outline action-button" id="htmlwidget-967b972875ac12da863c_prev">
+<div id="htmlwidget-2096806f57387e925ae8_menu">
+<span id="htmlwidget-2096806f57387e925ae8_menu_navi">
+<button type="button" class="btn bttn-no-outline action-button" id="htmlwidget-2096806f57387e925ae8_today">Today</button>
+<button type="button" class="btn bttn-no-outline action-button" id="htmlwidget-2096806f57387e925ae8_prev">
 <i class="fa fa-chevron-left"></i>
 </button>
-<button type="button" class="btn bttn-no-outline action-button" id="htmlwidget-967b972875ac12da863c_next">
+<button type="button" class="btn bttn-no-outline action-button" id="htmlwidget-2096806f57387e925ae8_next">
 <i class="fa fa-chevron-right"></i>
 </button>
 </span>
-<span id="htmlwidget-967b972875ac12da863c_renderRange" class="render-range"></span>
+<span id="htmlwidget-2096806f57387e925ae8_renderRange" class="render-range"></span>
 </div>
 <br/>
-<div id="htmlwidget-967b972875ac12da863c" style="width:100%;height:600px;" class="calendar html-widget" width="100%" height="600px"></div>
-<script type="application/json" data-for="htmlwidget-967b972875ac12da863c">{"x":{"options":{"defaultView":"month","taskView":false,"scheduleView":true,"useDetailPopup":true,"useCreationPopup":false,"isReadOnly":true,"usageStatistics":false,"month":{"startDayOfWeek":1,"narrowWeekend":true},"calendars":[{"id":1,"name":"PERSO","color":"#000","bgColor":"#c6d19d","borderColor":"forestgreen"},{"id":2,"name":"WORK","color":"#000","bgColor":"#F5A9A9","borderColor":"firebrick"},{"id":3,"name":"COURSES","color":"#000","bgColor":"#c6e2f6","borderColor":"#3b7cc6"}]},"schedules":[{"category":"time","dueDateClass":"","id":"schedule081a7451d1997f50015e1d98","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-01-03 10:00:00","end":"2023-01-03 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule540c69e83a6177eb5aaea8d1","calendarId":"2","title":"CDM WG : Pregnancy","body":"The Pregnancy and Maternal Medicine working group will present.","recurrenceRule":null,"start":"2023-01-17 13:00:00","end":"2023-01-17 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule51f9d18ec89ef6016920254f","calendarId":"1","title":"CDM WG Meeting : NLP","body":"The NLP working group will present some potential updates to the NOTE_NLP table.","recurrenceRule":null,"start":"2023-02-07 10:00:00","end":"2023-02-07 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulee0c07c4cf3c2e4ac06e0ccb3","calendarId":"2","title":"CDM WG Vocabulary Discussion","body":"Anna Ostropolets will join to ask us about our experiences using the OMOP Standard Vocabulary for ETL and other purposes","recurrenceRule":null,"start":"2023-02-21 13:00:00","end":"2023-02-21 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulef543c83e7463e9b01d7a3438","calendarId":"1","title":"CDM WG : HADES","body":"Martijn Schuemie will present about the HADES working group and how their work interconnects with the OMOP CDM","recurrenceRule":null,"start":"2023-03-07 9:00:00","end":"2023-03-07 10:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule6e0cfcdfd7e4a08de0c99d39","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-03-21 13:00:00","end":"2023-03-21 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule702be0ebc10631a7999888f9","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-04-04 10:00:00","end":"2023-04-04 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule855d1e35590d6abd4753601d","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-04-18 13:00:00","end":"2023-04-18 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulea5bd475e572aaf2c539b6aa7","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-05-02 10:00:00","end":"2023-05-02 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulef62e4de9a4da20e3c4247b17","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-05-16 13:00:00","end":"2023-05-16 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule779d8541da1af50141951dd1","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-06-06 10:00:00","end":"2023-06-06 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule19a495623a61ca0279ed7829","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-07-18 13:00:00","end":"2023-07-18 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulebbe3e7e7a7aeaa77614a5ec6","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-08-01 10:00:00","end":"2023-08-01 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule20ca316a29ad7136644c63d5","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-08-15 13:00:00","end":"2023-08-15 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulef9e0b028e8bfc3744c1532ee","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-09-05 10:00:00","end":"2023-09-05 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule1e16006108b4662ceca1216c","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-09-19 13:00:00","end":"2023-09-19 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"scheduleda785b2b16a6d171a1e893cc","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-10-03 10:00:00","end":"2023-10-03 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule95c5521681c11856c27af4be","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-10-17 13:00:00","end":"2023-10-17 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule2f43f948b02b25439a5988d3","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-11-07 10:00:00","end":"2023-11-07 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulef9d814e39014c2992328c750","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-11-21 13:00:00","end":"2023-11-21 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule13b54ae21f15e8e57f9f383d","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-12-05 10:00:00","end":"2023-12-05 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"scheduled04e82858ecd806f9b012ed1","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-12-19 13:00:00","end":"2023-12-19 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null}],"navigation":true,"defaultDate":"2023-02-07","events":[],"navigationOptions":{"today_label":"Today","prev_label":"<i class=\"fa fa-chevron-left\" role=\"presentation\" aria-label=\"chevron-left icon\"><\/i>","next_label":"<i class=\"fa fa-chevron-right\" role=\"presentation\" aria-label=\"chevron-right icon\"><\/i>","class":" bttn-bordered bttn-sm bttn-primary","fmt_date":"YYYY-MM-DD","sep_date":" ~ "}},"evals":[],"jsHooks":[]}</script>
+<div id="htmlwidget-2096806f57387e925ae8" style="width:100%;height:600px;" class="calendar html-widget" width="100%" height="600px"></div>
+<script type="application/json" data-for="htmlwidget-2096806f57387e925ae8">{"x":{"options":{"defaultView":"month","taskView":false,"scheduleView":true,"useDetailPopup":true,"useCreationPopup":false,"isReadOnly":true,"usageStatistics":false,"month":{"startDayOfWeek":1,"narrowWeekend":true},"calendars":[{"id":1,"name":"PERSO","color":"#000","bgColor":"#c6d19d","borderColor":"forestgreen"},{"id":2,"name":"WORK","color":"#000","bgColor":"#F5A9A9","borderColor":"firebrick"},{"id":3,"name":"COURSES","color":"#000","bgColor":"#c6e2f6","borderColor":"#3b7cc6"}]},"schedules":[{"category":"time","dueDateClass":"","id":"scheduleca1b5497d5d1bc144191f2b3","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-01-03 10:00:00","end":"2023-01-03 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule2e240e994b202048b6a0f29f","calendarId":"2","title":"CDM WG : Pregnancy","body":"The Pregnancy and Maternal Medicine working group will present.","recurrenceRule":null,"start":"2023-01-17 13:00:00","end":"2023-01-17 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule034876280bbb17a524c06ac9","calendarId":"1","title":"CDM WG Meeting : NLP","body":"The NLP working group will present some potential updates to the NOTE_NLP table.","recurrenceRule":null,"start":"2023-02-07 10:00:00","end":"2023-02-07 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule00c06276293e04b2127f2068","calendarId":"2","title":"CDM WG Vocabulary Discussion","body":"Anna Ostropolets will join to ask us about our experiences using the OMOP Standard Vocabulary for ETL and other purposes","recurrenceRule":null,"start":"2023-02-21 13:00:00","end":"2023-02-21 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulec21692f529ac7db5d04c5ac0","calendarId":"1","title":"CDM WG : HADES","body":"Martijn Schuemie will present about the HADES working group and how their work interconnects with the OMOP CDM","recurrenceRule":null,"start":"2023-03-07 9:00:00","end":"2023-03-07 10:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule5506afe3a3a0f6a29c758dad","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-03-21 13:00:00","end":"2023-03-21 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule3450081ddd59038a3c3e0749","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-04-04 10:00:00","end":"2023-04-04 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"scheduleab62c35a8b5abe22ac7cd62d","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-04-18 13:00:00","end":"2023-04-18 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule8416070f36e3b376232e958c","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-05-02 10:00:00","end":"2023-05-02 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"scheduleb60088b77b52b6220496807d","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-05-16 13:00:00","end":"2023-05-16 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulee2f334bea0f9502691bded38","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-06-06 10:00:00","end":"2023-06-06 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule6e1e8dcc0624d54989ac7fe2","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-07-18 13:00:00","end":"2023-07-18 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule2439c473cfe61015c29d324c","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-08-01 10:00:00","end":"2023-08-01 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule734e4451e8046f6850af5b1e","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-08-15 13:00:00","end":"2023-08-15 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule20a06d027feb5c7572ba7a27","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-09-05 10:00:00","end":"2023-09-05 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule74418278c8bdd3b5be361338","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-09-19 13:00:00","end":"2023-09-19 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"scheduledafc5ed3f1fbea697dd589f4","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-10-03 10:00:00","end":"2023-10-03 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulec5235fb9470acc02cb0588ad","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-10-17 13:00:00","end":"2023-10-17 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule9b6740ee3c9cb4bd19ec2d94","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-11-07 10:00:00","end":"2023-11-07 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulec92f2ecd8ee71b18aff1916c","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-11-21 13:00:00","end":"2023-11-21 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedule8b0493024d6829e5e2b9a589","calendarId":"1","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-12-05 10:00:00","end":"2023-12-05 11:00:00","location":"Teams: https://tinyurl.com/cdm1sttues","bgColor":null,"color":null,"borderColor":null},{"category":"time","dueDateClass":"","id":"schedulea6c5186feb65e305fe2bf1a4","calendarId":"2","title":"CDM WG Meeting","body":"","recurrenceRule":null,"start":"2023-12-19 13:00:00","end":"2023-12-19 14:00:00","location":"Teams: https://tinyurl.com/cdm3rdtues","bgColor":null,"color":null,"borderColor":null}],"navigation":true,"defaultDate":"2023-02-08","events":[],"navigationOptions":{"today_label":"Today","prev_label":"<i class=\"fa fa-chevron-left\" role=\"presentation\" aria-label=\"chevron-left icon\"><\/i>","next_label":"<i class=\"fa fa-chevron-right\" role=\"presentation\" aria-label=\"chevron-right icon\"><\/i>","class":" bttn-bordered bttn-sm bttn-primary","fmt_date":"YYYY-MM-DD","sep_date":" ~ "}},"evals":[],"jsHooks":[]}</script>
 </div>
 </div>
 <div id="current-cdm-version" class="section level2">
diff --git a/docs/indices-primary-foreign.html b/docs/indices-primary-foreign.html
index 9c50a1d4..38a46dec 100644
--- a/docs/indices-primary-foreign.html
+++ b/docs/indices-primary-foreign.html
@@ -13,7 +13,7 @@
 
 <title>Indices, Primary Keys and Foreign Key Constraints</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -487,28 +491,50 @@
 
 
 
-<h1 class="title toc-ignore">Indices, Primary Keys and Foreign Key Constraints</h1>
+<h1 class="title toc-ignore">Indices, Primary Keys and Foreign Key
+Constraints</h1>
 
 </div>
 
 
 <div id="overview" class="section level2">
 <h2>Overview</h2>
-<p>Database indices improve the performance of queries against a database by organizing the data in a way that increase query execution.</p>
-<p>This article was written to provide guidance on the setting of indices, primary and foreign keys for data that has been transformed into the Observational Medical Outcome Partnership (OMOP) Common Data Model (CDM). The community that supports the design and development of the OHDSI/CommonDataModel Github repository is a diverse collaborative of healthcare and technical profesisonals whom have limited data base adminstrative (DBA) experience. As a result, the comments below should be interpreted as suggestions and recommendations to help increase performance. Your teams needs may call for a modified configuration.</p>
+<p>Database indices improve the performance of queries against a
+database by organizing the data in a way that increase query
+execution.</p>
+<p>This article was written to provide guidance on the setting of
+indices, primary and foreign keys for data that has been transformed
+into the Observational Medical Outcome Partnership (OMOP) Common Data
+Model (CDM). The community that supports the design and development of
+the OHDSI/CommonDataModel Github repository is a diverse collaborative
+of healthcare and technical profesisonals whom have limited data base
+adminstrative (DBA) experience. As a result, the comments below should
+be interpreted as suggestions and recommendations to help increase
+performance. Your teams needs may call for a modified configuration.</p>
 </div>
 <div id="general-recommendations" class="section level2">
 <h2>General Recommendations</h2>
-<p>Should your database of choice support indexing, the OMOP CDM Working Group recommends</p>
+<p>Should your database of choice support indexing, the OMOP CDM Working
+Group recommends</p>
 <ul>
-<li>Indexing on all columns containing an "_id" (e.g. condition_occurrence_id, drug_exposure_id, measurement_id, procedure_occurrence_id, etc.)</li>
+<li>Indexing on all columns containing an “_id”
+(e.g. condition_occurrence_id, drug_exposure_id, measurement_id,
+procedure_occurrence_id, etc.)</li>
 <li>Indexing on primary and foreign keys</li>
 </ul>
-<p>For all databases, regardless of custom indice support, primary and foreign keys should be set. This is a step towards ensuring data integrity. Information on what table level attributes should be set as primary and foreign keys can be found within the *_Field_Level.csv file(s) located in the <a href="https://github.com/OHDSI/CommonDataModel/tree/v5.4/inst/csv">INST/CSV directory</a></p>
+<p>For all databases, regardless of custom indice support, primary and
+foreign keys should be set. This is a step towards ensuring data
+integrity. Information on what table level attributes should be set as
+primary and foreign keys can be found within the *_Field_Level.csv
+file(s) located in the <a
+href="https://github.com/OHDSI/CommonDataModel/tree/v5.4/inst/csv">INST/CSV
+directory</a></p>
 </div>
 <div id="database-support" class="section level2">
 <h2>Database support</h2>
-<p>The OHDSI/CommonDataModel package leverages OHDSI/SQLRender and as a result is only capable of supporting sources that are supported by OHDSI/SQLRender. The following databases are currently supported.</p>
+<p>The OHDSI/CommonDataModel package leverages OHDSI/SQLRender and as a
+result is only capable of supporting sources that are supported by
+OHDSI/SQLRender. The following databases are currently supported.</p>
 <div id="microsoft-sql-server" class="section level3">
 <h3>Microsoft SQL Server</h3>
 </div>
@@ -520,7 +546,12 @@ <h3>PostgreSQL</h3>
 </div>
 <div id="amazon-redshift" class="section level3">
 <h3>Amazon Redshift</h3>
-<p>On AWS Redshift it is important to ensure that your data is properly distributed and sorted across nodes. Compression on certain columns may also help. The designed DDL does set DISTKEYS in an effort to optimize performance. This configuration can be seen within the <a href="https://github.com/OHDSI/CommonDataModel/blob/v5.4/ddl/5.4/redshift/OMOPCDM_redshift_5.4_ddl.sql">Redshift-specific DDL</a>.</p>
+<p>On AWS Redshift it is important to ensure that your data is properly
+distributed and sorted across nodes. Compression on certain columns may
+also help. The designed DDL does set DISTKEYS in an effort to optimize
+performance. This configuration can be seen within the <a
+href="https://github.com/OHDSI/CommonDataModel/blob/v5.4/ddl/5.4/redshift/OMOPCDM_redshift_5.4_ddl.sql">Redshift-specific
+DDL</a>.</p>
 </div>
 <div id="impala" class="section level3">
 <h3>Impala</h3>
@@ -530,7 +561,10 @@ <h3>IBM Netezza</h3>
 </div>
 <div id="google-bigquery" class="section level3">
 <h3>Google BigQuery</h3>
-<p>Google BigQuery does not require manual optimization and/or sizing. Google BigQuery does massive parallel full table scans and intensive caching, all under the hood. <a href="https://forums.ohdsi.org/t/iso-best-practices-of-cdm-indexing/10939/2">Reference</a></p>
+<p>Google BigQuery does not require manual optimization and/or sizing.
+Google BigQuery does massive parallel full table scans and intensive
+caching, all under the hood. <a
+href="https://forums.ohdsi.org/t/iso-best-practices-of-cdm-indexing/10939/2">Reference</a></p>
 </div>
 <div id="microsoft-parallel-data-warehouse-pdw" class="section level3">
 <h3>Microsoft Parallel Data Warehouse (PDW)</h3>
@@ -540,12 +574,16 @@ <h3>SQLite</h3>
 </div>
 <div id="databricks" class="section level3">
 <h3>Databricks</h3>
-<p>This database type is not yet supported but is actively being worked on by a number of collaborators. For more informtion, please contact Ajit Londhe of Amgen.</p>
+<p>This database type is not yet supported but is actively being worked
+on by a number of collaborators. For more informtion, please contact
+Ajit Londhe of Amgen.</p>
 </div>
 </div>
 <div id="references" class="section level2">
 <h2>References</h2>
-<p><a href="https://forums.ohdsi.org/t/iso-best-practices-of-cdm-indexing/10939/2">ISO Best Practices of CDM Indexing</a></p>
+<p><a
+href="https://forums.ohdsi.org/t/iso-best-practices-of-cdm-indexing/10939/2">ISO
+Best Practices of CDM Indexing</a></p>
 </div>
 
 
diff --git a/docs/leaveAsIs.html b/docs/leaveAsIs.html
index 1feb8db8..db45322a 100644
--- a/docs/leaveAsIs.html
+++ b/docs/leaveAsIs.html
@@ -13,7 +13,7 @@
 
 <title>Leave As Is</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,7 +420,13 @@ <h1 class="title toc-ignore">Leave As Is</h1>
 </div>
 
 
-<p>Okay, so you do not have a network use case but multiple collaborators have access to the element you are interested in adding to the CDM. <strong>In this circumstance, the CDM Working Group suggests leaving the model as-is.</strong> Without a network use case there is no need to augment the data model. If this is something you need for your work, consider a <a href="localChange.html">local change</a> or a model extension.</p>
+<p>Okay, so you do not have a network use case but multiple
+collaborators have access to the element you are interested in adding to
+the CDM. <strong>In this circumstance, the CDM Working Group suggests
+leaving the model as-is.</strong> Without a network use case there is no
+need to augment the data model. If this is something you need for your
+work, consider a <a href="localChange.html">local change</a> or a model
+extension.</p>
 
 
 
diff --git a/docs/localChange.html b/docs/localChange.html
index 247f9e80..dd774fc2 100644
--- a/docs/localChange.html
+++ b/docs/localChange.html
@@ -13,7 +13,7 @@
 
 <title>Local Change</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,7 +420,13 @@ <h1 class="title toc-ignore">Local Change</h1>
 </div>
 
 
-<p>Since you do not have a network use case and this element is specific to your data source, <strong>feel free to create a local change to your instance of the OMOP Common Data Model.</strong> Augmenting the model at your institution for administrative purposes or other in-house needs is totally acceptable with the understanding that any local changes cannot and should not be relied upon in network studies or supported by the open-source tools.</p>
+<p>Since you do not have a network use case and this element is specific
+to your data source, <strong>feel free to create a local change to your
+instance of the OMOP Common Data Model.</strong> Augmenting the model at
+your institution for administrative purposes or other in-house needs is
+totally acceptable with the understanding that any local changes cannot
+and should not be relied upon in network studies or supported by the
+open-source tools.</p>
 
 
 
diff --git a/docs/networkUseCase.html b/docs/networkUseCase.html
index ced85b9e..cddcb7ff 100644
--- a/docs/networkUseCase.html
+++ b/docs/networkUseCase.html
@@ -13,7 +13,7 @@
 
 <title>Network Use Case</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,7 +420,12 @@ <h1 class="title toc-ignore">Network Use Case</h1>
 </div>
 
 
-<p>Alright, so you think you might need to change the OMOP Common Data Model. <strong>Do you have a documented network use case for this data need? This could take the form of an upcoming study or a convention for how to store information.</strong> In this scenario, at least two or more collaborators with data to contribute constitute a network need.</p>
+<p>Alright, so you think you might need to change the OMOP Common Data
+Model. <strong>Do you have a documented network use case for this data
+need? This could take the form of an upcoming study or a convention for
+how to store information.</strong> In this scenario, at least two or
+more collaborators with data to contribute constitute a network
+need.</p>
 <p><a href="useCaseY.html">Yes, I have a network use case</a></p>
 <p><a href="useCaseN.html">No, I do not have a network use case</a></p>
 
diff --git a/docs/oncology.html b/docs/oncology.html
index ca4e87cb..b86443e4 100644
--- a/docs/oncology.html
+++ b/docs/oncology.html
@@ -13,7 +13,7 @@
 
 <title>Oncology Extension</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -492,34 +496,75 @@ <h1 class="title toc-ignore">Oncology Extension</h1>
 </div>
 
 
-<div id="omop-common-data-model-oncology-extension-documentation" class="section level2">
+<div id="omop-common-data-model-oncology-extension-documentation"
+class="section level2">
 <h2>OMOP Common Data Model Oncology Extension Documentation</h2>
-<p>This documentation details the ratified proposal of adding an oncology extension to the OMOP CDM. These tables and fields will become part of the next release (v6.1) of the Common Data Model. Below are their descriptions; showing <em>additions</em> to the model only. For example, two fields were added to the MEASUREMENT table as part of this extension so only those two fields are listed below for MEASUREMENT instead of the entire table. For more information, please see the <a href="https://github.com/OHDSI/OncologyWG/wiki">OMOP Oncology wiki site</a>.</p>
-<p>The DDLs for these tables are located on the Oncology github, as detailed in the <a href="https://github.com/OHDSI/OncologyWG/wiki/Oncology-CDM-Extension-Installation">installation instructions</a>.</p>
-<pre><code>## Warning in read.table(file = file, header = header, sep = sep, quote = quote, : incomplete final line found
-## by readTableHeader on &#39;../inst/csv/OMOP_CDM_Oncology_Ex_Table_Level.csv&#39;</code></pre>
+<p>This documentation details the ratified proposal of adding an
+oncology extension to the OMOP CDM. These tables and fields will become
+part of the next release (v6.1) of the Common Data Model. Below are
+their descriptions; showing <em>additions</em> to the model only. For
+example, two fields were added to the MEASUREMENT table as part of this
+extension so only those two fields are listed below for MEASUREMENT
+instead of the entire table. For more information, please see the <a
+href="https://github.com/OHDSI/OncologyWG/wiki">OMOP Oncology wiki
+site</a>.</p>
+<p>The DDLs for these tables are located on the Oncology github, as
+detailed in the <a
+href="https://github.com/OHDSI/OncologyWG/wiki/Oncology-CDM-Extension-Installation">installation
+instructions</a>.</p>
+<pre><code>## Warning in read.table(file = file, header = header, sep = sep, quote = quote, : incomplete final line found by
+## readTableHeader on &#39;../inst/csv/OMOP_CDM_Oncology_Ex_Table_Level.csv&#39;</code></pre>
 <div id="episode" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">EPISODE</h3>
 <p><strong>Table Description</strong></p>
-<p>The EPISODE table aggregates lower-level clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) into a higher-level abstraction representing clinically and analytically relevant disease phases,outcomes and treatments. The EPISODE_EVENT table connects qualifying clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry. For example cancers including their development over time, their treatment, and final resolution.</p>
+<p>The EPISODE table aggregates lower-level clinical events
+(VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE)
+into a higher-level abstraction representing clinically and analytically
+relevant disease phases,outcomes and treatments. The EPISODE_EVENT table
+connects qualifying clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE,
+PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry.
+For example cancers including their development over time, their
+treatment, and final resolution.</p>
 <p><strong>User Guide</strong></p>
-<p>Valid Episode Concepts belong to the ‘Episode’ domain. For cancer episodes please see [article], for non-cancer episodes please see [article]. If your source data does not have all episodes that are relevant to the therapeutic area, write only those you can easily derive from the data. It is understood that that table is not currently expected to be comprehensive.</p>
+<p>Valid Episode Concepts belong to the ‘Episode’ domain. For cancer
+episodes please see [article], for non-cancer episodes please see
+[article]. If your source data does not have all episodes that are
+relevant to the therapeutic area, write only those you can easily derive
+from the data. It is understood that that table is not currently
+expected to be comprehensive.</p>
 </div>
 <div id="episode_event" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">EPISODE_EVENT</h3>
 <p><strong>Table Description</strong></p>
-<p>The EPISODE_EVENT table connects qualifying clinical events (such as CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT) to the appropriate EPISODE entry. For example, linking the precise location of the metastasis (cancer modifier in MEASUREMENT) to the disease episode.</p>
+<p>The EPISODE_EVENT table connects qualifying clinical events (such as
+CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT)
+to the appropriate EPISODE entry. For example, linking the precise
+location of the metastasis (cancer modifier in MEASUREMENT) to the
+disease episode.</p>
 <p><strong>User Guide</strong></p>
-<p>This connecting table is used instead of the FACT_RELATIONSHIP table for linking low-level events to abstracted Episodes.</p>
+<p>This connecting table is used instead of the FACT_RELATIONSHIP table
+for linking low-level events to abstracted Episodes.</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Some episodes may not have links to any underlying clinical events. For such episodes, the EPISODE_EVENT table is not populated.</p>
+<p>Some episodes may not have links to any underlying clinical events.
+For such episodes, the EPISODE_EVENT table is not populated.</p>
 </div>
 <div id="measurement" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">MEASUREMENT</h3>
 <p><strong>Table Description</strong></p>
-<p>The MEASUREMENT table contains records of Measurement, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID).</p>
+<p>The MEASUREMENT table contains records of Measurement,
+i.e. structured values (numerical or categorical) obtained through
+systematic and standardized examination or testing of a Person or
+Person’s sample. The MEASUREMENT table contains both orders and results
+of such Measurements as laboratory tests, vital signs, quantitative
+findings from pathology reports, etc. Measurements are stored as
+attribute value pairs, with the attribute as the Measurement Concept and
+the value representing the result. The value can be a Concept (stored in
+VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit
+(UNIT_CONCEPT_ID).</p>
 <p><strong>User Guide</strong></p>
-<p>Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result.</p>
+<p>Measurements differ from Observations in that they require a
+standardized test or some other activity to generate a quantitative or
+qualitative result.</p>
 </div>
 </div>
 
diff --git a/docs/queries.html b/docs/queries.html
index 72e19539..6b80bba0 100644
--- a/docs/queries.html
+++ b/docs/queries.html
@@ -15,7 +15,7 @@
 
 <title>Example_Queries</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -147,11 +147,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -253,7 +257,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -420,8 +424,24 @@ <h4 class="date">September 29, 2020</h4>
 </div>
 
 
-<p>The query below will find all standard concepts in the Visit domain that do not have any ancestors. These are considered “top-level” visit concepts and can be used to define categories of visits in cohort definitions. For example, the Inpatient Visit concept <a href="https://athena.ohdsi.org/search-terms/terms/9201">9201</a> subsumes the concepts for Inpatient Hospital and Inpatient in Psychiatric Facility. Instead of creating a concept set with all of these terms to define an inpatient visit you can use 9201 and all of it’s descendants, a concept found using the top-level query.</p>
-<p>WITH top_level AS (SELECT concept_id, concept_name FROM concept LEFT JOIN concept_ancestor ON concept_id=descendant_concept_id AND ancestor_concept_id!=descendant_concept_id WHERE domain_id=‘Visit’ AND standard_concept=‘S’ AND ancestor_concept_id IS NULL ) SELECT top_level.concept_id, top_level.concept_name, descendant.concept_id, descendant.concept_name FROM concept_ancestor JOIN top_level ON top_level.concept_id = ancestor_concept_id JOIN concept descendant ON descendant.concept_id = descendant_concept_id WHERE descendant.domain_id = ‘Visit’;</p>
+<p>The query below will find all standard concepts in the Visit domain
+that do not have any ancestors. These are considered “top-level” visit
+concepts and can be used to define categories of visits in cohort
+definitions. For example, the Inpatient Visit concept <a
+href="https://athena.ohdsi.org/search-terms/terms/9201">9201</a>
+subsumes the concepts for Inpatient Hospital and Inpatient in
+Psychiatric Facility. Instead of creating a concept set with all of
+these terms to define an inpatient visit you can use 9201 and all of
+it’s descendants, a concept found using the top-level query.</p>
+<p>WITH top_level AS (SELECT concept_id, concept_name FROM concept LEFT
+JOIN concept_ancestor ON concept_id=descendant_concept_id AND
+ancestor_concept_id!=descendant_concept_id WHERE domain_id=‘Visit’ AND
+standard_concept=‘S’ AND ancestor_concept_id IS NULL ) SELECT
+top_level.concept_id, top_level.concept_name, descendant.concept_id,
+descendant.concept_name FROM concept_ancestor JOIN top_level ON
+top_level.concept_id = ancestor_concept_id JOIN concept descendant ON
+descendant.concept_id = descendant_concept_id WHERE descendant.domain_id
+= ‘Visit’;</p>
 
 
 
diff --git a/docs/reviewProposals.html b/docs/reviewProposals.html
index 06f079a3..ca6da271 100644
--- a/docs/reviewProposals.html
+++ b/docs/reviewProposals.html
@@ -13,7 +13,7 @@
 
 <title>CDM Proposals Under Review</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,7 +420,10 @@ <h1 class="title toc-ignore">CDM Proposals Under Review</h1>
 </div>
 
 
-<p>This page is still in development. For a list of all proposals currently under review please see the <a href="https://github.com/OHDSI/CommonDataModel/issues?utf8=%E2%9C%93&amp;q=is%3Aissue%20label%3AProposal%20">github issue log</a>.</p>
+<p>This page is still in development. For a list of all proposals
+currently under review please see the <a
+href="https://github.com/OHDSI/CommonDataModel/issues?utf8=%E2%9C%93&amp;q=is%3Aissue%20label%3AProposal%20">github
+issue log</a>.</p>
 
 
 
diff --git a/docs/site_libs/header-attrs-2.13/header-attrs.js b/docs/site_libs/header-attrs-2.13/header-attrs.js
deleted file mode 100644
index dd57d92e..00000000
--- a/docs/site_libs/header-attrs-2.13/header-attrs.js
+++ /dev/null
@@ -1,12 +0,0 @@
-// Pandoc 2.9 adds attributes on both header and div. We remove the former (to
-// be compatible with the behavior of Pandoc < 2.8).
-document.addEventListener('DOMContentLoaded', function(e) {
-  var hs = document.querySelectorAll("div.section[class*='level'] > :first-child");
-  var i, h, a;
-  for (i = 0; i < hs.length; i++) {
-    h = hs[i];
-    if (!/^h[1-6]$/i.test(h.tagName)) continue;  // it should be a header h1-h6
-    a = h.attributes;
-    while (a.length > 0) h.removeAttribute(a[0].name);
-  }
-});
diff --git a/docs/sqlScripts.html b/docs/sqlScripts.html
index 6fb3a26c..22c6aa37 100644
--- a/docs/sqlScripts.html
+++ b/docs/sqlScripts.html
@@ -13,7 +13,7 @@
 
 <title>sqlScripts.knit</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -493,12 +497,20 @@
 
 <div id="sql-scripts" class="section level1">
 <h1><strong>SQL Scripts</strong></h1>
-<p>These SQL scripts have been developed by the community to facilitate the Extract, Transform, and Load (ETL) process from source data to the OMOP CDM.</p>
+<p>These SQL scripts have been developed by the community to facilitate
+the Extract, Transform, and Load (ETL) process from source data to the
+OMOP CDM.</p>
 <div id="vocabulary-mapping" class="section level2">
 <h2><strong>Vocabulary Mapping</strong></h2>
 <div id="source-to-standard" class="section level3">
 <h3>Source to Standard</h3>
-<p>This script will create a large table containing all source codes and the Standard Concepts they map to. By creating this table ahead of time and referencing it during ETL, you can save processing time than if you were to map source codes on the fly. It is important to note that this script will show ALL mappings, not just those to Standard, Valid Concepts. Be sure to add a filter that will only grab the correct Standard, Valid codes.</p>
+<p>This script will create a large table containing all source codes and
+the Standard Concepts they map to. By creating this table ahead of time
+and referencing it during ETL, you can save processing time than if you
+were to map source codes on the fly. It is important to note that this
+script will show ALL mappings, not just those to Standard, Valid
+Concepts. Be sure to add a filter that will only grab the correct
+Standard, Valid codes.</p>
 <pre class="sql"><code>SELECT c.concept_code AS SOURCE_CODE, c.concept_id AS SOURCE_CONCEPT_ID, c.concept_name AS SOURCE_CODE_DESCRIPTION, c.vocabulary_id AS SOURCE_VOCABULARY_ID, c.domain_id AS SOURCE_DOMAIN_ID, c.CONCEPT_CLASS_ID AS SOURCE_CONCEPT_CLASS_ID, c.VALID_START_DATE AS SOURCE_VALID_START_DATE, c.VALID_END_DATE AS SOURCE_VALID_END_DATE, c.INVALID_REASON AS SOURCE_INVALID_REASON, c1.concept_id AS TARGET_CONCEPT_ID, c1.concept_name AS TARGET_CONCEPT_NAME, c1.VOCABULARY_ID AS TARGET_VOCABUALRY_ID, c1.domain_id AS TARGET_DOMAIN_ID, c1.concept_class_id AS TARGET_CONCEPT_CLASS_ID, c1.INVALID_REASON AS TARGET_INVALID_REASON, c1.standard_concept AS TARGET_STANDARD_CONCEPT
        FROM CONCEPT C
              JOIN CONCEPT_RELATIONSHIP CR
@@ -520,7 +532,13 @@ <h3>Source to Standard</h3>
 </div>
 <div id="source-to-source" class="section level3">
 <h3>Source to Source</h3>
-<p>This script will create a large table containing all source codes and their referent Concepts. While you may be tempted to use the Source to Standard query to find these, it is important to use this one instead to populate *_SOURCE_CONCEPT_ID fields. Some source codes map to multiple Standard Concepts though they have only one source Concept. By using the Source to Standard query you may inadvertently create duplicate records in your CDM instance.</p>
+<p>This script will create a large table containing all source codes and
+their referent Concepts. While you may be tempted to use the Source to
+Standard query to find these, it is important to use this one instead to
+populate *_SOURCE_CONCEPT_ID fields. Some source codes map to multiple
+Standard Concepts though they have only one source Concept. By using the
+Source to Standard query you may inadvertently create duplicate records
+in your CDM instance.</p>
 <pre class="sql"><code>SELECT c.concept_code AS SOURCE_CODE, c.concept_id AS SOURCE_CONCEPT_ID, c.CONCEPT_NAME AS SOURCE_CODE_DESCRIPTION, c.vocabulary_id AS SOURCE_VOCABULARY_ID, c.domain_id AS SOURCE_DOMAIN_ID, c.concept_class_id AS SOURCE_CONCEPT_CLASS_ID, c.VALID_START_DATE AS SOURCE_VALID_START_DATE, c.VALID_END_DATE AS SOURCE_VALID_END_DATE, c.invalid_reason AS SOURCE_INVALID_REASON, c.concept_ID as TARGET_CONCEPT_ID, c.concept_name AS TARGET_CONCEPT_NAME, c.vocabulary_id AS TARGET_VOCABULARY_ID, c.domain_id AS TARGET_DOMAIN_ID, c.concept_class_id AS TARGET_CONCEPT_CLASS_ID, c.INVALID_REASON AS TARGET_INVALID_REASON, c.STANDARD_CONCEPT AS TARGET_STANDARD_CONCEPT
        FROM CONCEPT c
        UNION
@@ -537,7 +555,11 @@ <h3>Source to Source</h3>
 <h2><strong>Era Tables</strong></h2>
 <div id="condition-eras" class="section level3">
 <h3>Condition Eras</h3>
-<p>This script will insert values into the CONDITION_ERA table given that the CONDITION_OCCURRENCE table is populated. It will string together condition records that have &lt;= 30 days between them into eras during which the Person is assumed to have the given condition. <strong>NOTE</strong> This query only works with 5.3 and below.</p>
+<p>This script will insert values into the CONDITION_ERA table given
+that the CONDITION_OCCURRENCE table is populated. It will string
+together condition records that have &lt;= 30 days between them into
+eras during which the Person is assumed to have the given condition.
+<strong>NOTE</strong> This query only works with 5.3 and below.</p>
 <pre class="sql"><code>/****************************************************
 OHDSI-SQL File Instructions
 -----------------------------
@@ -708,7 +730,12 @@ <h3>Condition Eras</h3>
 </div>
 <div id="drug-eras" class="section level3">
 <h3>Drug Eras</h3>
-<p>If the DRUG_EXPOSURE table is populated this script will string together periods of time that a person is exposed to an active drug ingredient, allowing for 30 gaps in between. It will then insert the resulting era records into the DRUG_ERA table. <strong>NOTE</strong> This query only works with the <strong>version 5</strong> series and below.</p>
+<p>If the DRUG_EXPOSURE table is populated this script will string
+together periods of time that a person is exposed to an active drug
+ingredient, allowing for 30 gaps in between. It will then insert the
+resulting era records into the DRUG_ERA table. <strong>NOTE</strong>
+This query only works with the <strong>version 5</strong> series and
+below.</p>
 <pre class="sql"><code>
 -- Code taken from:
 -- https://github.com/OHDSI/ETL-CMS/blob/master/SQL/create_CDMv5_drug_era_non_stockpile.sql
@@ -878,7 +905,13 @@ <h3>Drug Eras</h3>
 <h2><strong>Example ETL Script</strong></h2>
 <div id="cdm_source-table" class="section level3">
 <h3>CDM_SOURCE Table</h3>
-<p>The script below is an example for how to fill in the CDM_SOURCE table. This table is required for the <a href="https://github.com/OHDSI/DataQualityDashboard">Data Quality Dashboard</a> package to run. This was taken from the <a href="https://github.com/OHDSI/ETL-Synthea">ETL-Synthea</a> package, a good example on how to write a complete extract-transform-load script from start to finish, including vocabulary import.</p>
+<p>The script below is an example for how to fill in the CDM_SOURCE
+table. This table is required for the <a
+href="https://github.com/OHDSI/DataQualityDashboard">Data Quality
+Dashboard</a> package to run. This was taken from the <a
+href="https://github.com/OHDSI/ETL-Synthea">ETL-Synthea</a> package, a
+good example on how to write a complete extract-transform-load script
+from start to finish, including vocabulary import.</p>
 <pre class="sql"><code>insert into @cdm_schema.cdm_source (
 cdm_source_name,
 cdm_source_abbreviation,
@@ -910,7 +943,17 @@ <h3>CDM_SOURCE Table</h3>
 <h2><strong>Bonus Queries</strong></h2>
 <div id="visit-concept-roll-up" class="section level3">
 <h3>Visit Concept Roll-up</h3>
-<p>The query below will utilize the Visit Concept hierarcy to find the highest-level ancestors. In the case that both the VISIT_OCCURRENCE and VISIT_DETAIL tables are populated, it is good practice (though not required) to use the highest-level ancestors as the VISIT_CONCEPT_IDs in the VISIT_OCCURRENCE table and their children as the VISIT_DETAIL_CONCEPT_IDs in the VISIT_DETAIL table. This relationship between the VISIT_OCCURRENCE and VISIT_DETAIL tables allow for standardized Visit logic to be written, building Visits from Visit Details. For more information on how this can be done, please see the <a href="https://ohdsi.github.io/ETL-LambdaBuilder/Optum%20Clinformatics/Optum_visit_occurrence.html">Optum Extended ETL documentation</a>.</p>
+<p>The query below will utilize the Visit Concept hierarcy to find the
+highest-level ancestors. In the case that both the VISIT_OCCURRENCE and
+VISIT_DETAIL tables are populated, it is good practice (though not
+required) to use the highest-level ancestors as the VISIT_CONCEPT_IDs in
+the VISIT_OCCURRENCE table and their children as the
+VISIT_DETAIL_CONCEPT_IDs in the VISIT_DETAIL table. This relationship
+between the VISIT_OCCURRENCE and VISIT_DETAIL tables allow for
+standardized Visit logic to be written, building Visits from Visit
+Details. For more information on how this can be done, please see the <a
+href="https://ohdsi.github.io/ETL-LambdaBuilder/Optum%20Clinformatics/Optum_visit_occurrence.html">Optum
+Extended ETL documentation</a>.</p>
 <pre class="sql"><code>SELECT concept_id, concept_name
   FROM concept 
   LEFT JOIN concept_ancestor 
diff --git a/docs/useCaseN.html b/docs/useCaseN.html
index 2d0af167..a9f0525a 100644
--- a/docs/useCaseN.html
+++ b/docs/useCaseN.html
@@ -13,7 +13,7 @@
 
 <title>Local Data</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,9 +420,14 @@ <h1 class="title toc-ignore">Local Data</h1>
 </div>
 
 
-<p>Okay, so you don’t have a network use case. <strong>Is this data element specific to your data source, or are there others in the community who might also have this data but don’t yet need it for a study or data model convention?</strong></p>
-<p><a href="localChange.html">Yes, this element is specific to my data source</a></p>
-<p><a href="leaveAsIs.html">No, there are others in the community who also have this data</a></p>
+<p>Okay, so you don’t have a network use case. <strong>Is this data
+element specific to your data source, or are there others in the
+community who might also have this data but don’t yet need it for a
+study or data model convention?</strong></p>
+<p><a href="localChange.html">Yes, this element is specific to my data
+source</a></p>
+<p><a href="leaveAsIs.html">No, there are others in the community who
+also have this data</a></p>
 
 
 
diff --git a/docs/useCaseY.html b/docs/useCaseY.html
index f0f2c789..098fdeef 100644
--- a/docs/useCaseY.html
+++ b/docs/useCaseY.html
@@ -13,7 +13,7 @@
 
 <title>OMOP Vocabulary</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -417,9 +421,13 @@ <h1 class="title toc-ignore">OMOP Vocabulary</h1>
 
 
 <p>Great, you have a network use case!</p>
-<p>Next question: <strong>Is there an existing OMOP vocabulary to support this new element? If you are unsure, feel free to check <a href="https://athena.ohdsi.org/search-terms/terms?query">Athena</a>.</strong></p>
-<p><a href="vocabY.html">Yes, I have all the required vocabulary I need</a></p>
-<p><a href="vocabN.html">No, I there is not an existing OMOP vocabulary to support my request</a></p>
+<p>Next question: <strong>Is there an existing OMOP vocabulary to
+support this new element? If you are unsure, feel free to check <a
+href="https://athena.ohdsi.org/search-terms/terms?query">Athena</a>.</strong></p>
+<p><a href="vocabY.html">Yes, I have all the required vocabulary I
+need</a></p>
+<p><a href="vocabN.html">No, I there is not an existing OMOP vocabulary
+to support my request</a></p>
 
 
 
diff --git a/docs/vocabN.html b/docs/vocabN.html
index f8326922..83aade15 100644
--- a/docs/vocabN.html
+++ b/docs/vocabN.html
@@ -13,7 +13,7 @@
 
 <title>Open Source Vocabulary</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,9 +420,14 @@ <h1 class="title toc-ignore">Open Source Vocabulary</h1>
 </div>
 
 
-<p>Okay, so you have a use case but you don’t have an OMOP vocabulary to support your need. <strong>Is there an existing open-source (not proprietary or custom) vocabulary that has not yet been incorporated into the OMOP vocabulary?</strong></p>
-<p><a href="vocabRequest.html">Yes, the vocabulary exists, it just needs to be brought in</a></p>
-<p><a href="contactVocab.html">No, there is no open-source vocabulary for this data element</a></p>
+<p>Okay, so you have a use case but you don’t have an OMOP vocabulary to
+support your need. <strong>Is there an existing open-source (not
+proprietary or custom) vocabulary that has not yet been incorporated
+into the OMOP vocabulary?</strong></p>
+<p><a href="vocabRequest.html">Yes, the vocabulary exists, it just needs
+to be brought in</a></p>
+<p><a href="contactVocab.html">No, there is no open-source vocabulary
+for this data element</a></p>
 
 
 
diff --git a/docs/vocabRequest.html b/docs/vocabRequest.html
index ede123fd..b6626ddb 100644
--- a/docs/vocabRequest.html
+++ b/docs/vocabRequest.html
@@ -13,7 +13,7 @@
 
 <title>Vocabulary Request</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,9 +420,21 @@ <h1 class="title toc-ignore">Vocabulary Request</h1>
 </div>
 
 
-<p>Okay so you have something you would like to add to the CDM and there is an existing OMOP vocabulary we can bring in to support it. <strong>In this case, please open an issue on the vocabulary github with the details of what you need added</strong> as data elements in the CDM must have a vocabulary in place before they can be implemented. The team will follow up with you should they need additional information.</p>
-<p><a href="https://github.com/OHDSI/Vocabulary-v5.0/issues">Vocabulary GitHub Issue Tracker</a></p>
-<p>Once that request is made, please follow the <a href="cdmRequestProcess.html">CDM Request Process</a> to begin the steps soliciting a change or addition to the model itself. Need more guidance? Consider contacting the CDM Working Group on our <a href="https://github.com/OHDSI/CommonDataModel">GitHub</a> or <a href="https://teams.microsoft.com/l/team/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/conversations?groupId=a6f2c516-e568-4974-8f1e-a7bdc2f997c5&amp;tenantId=a30f0094-9120-4aab-ba4c-e5509023b2d5">Teams Channel</a>.</p>
+<p>Okay so you have something you would like to add to the CDM and there
+is an existing OMOP vocabulary we can bring in to support it. <strong>In
+this case, please open an issue on the vocabulary github with the
+details of what you need added</strong> as data elements in the CDM must
+have a vocabulary in place before they can be implemented. The team will
+follow up with you should they need additional information.</p>
+<p><a href="https://github.com/OHDSI/Vocabulary-v5.0/issues">Vocabulary
+GitHub Issue Tracker</a></p>
+<p>Once that request is made, please follow the <a
+href="cdmRequestProcess.html">CDM Request Process</a> to begin the steps
+soliciting a change or addition to the model itself. Need more guidance?
+Consider contacting the CDM Working Group on our <a
+href="https://github.com/OHDSI/CommonDataModel">GitHub</a> or <a
+href="https://teams.microsoft.com/l/team/19%3a133f2b94b86a41a884d4a4d160610148%40thread.tacv2/conversations?groupId=a6f2c516-e568-4974-8f1e-a7bdc2f997c5&amp;tenantId=a30f0094-9120-4aab-ba4c-e5509023b2d5">Teams
+Channel</a>.</p>
 
 
 
diff --git a/docs/vocabY.html b/docs/vocabY.html
index f32dedbc..460b13f9 100644
--- a/docs/vocabY.html
+++ b/docs/vocabY.html
@@ -13,7 +13,7 @@
 
 <title>Request Process</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -145,11 +145,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -251,7 +255,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -416,7 +420,9 @@ <h1 class="title toc-ignore">Request Process</h1>
 </div>
 
 
-<p>Great, so you have a network use case and an existing OMOP Vocabulary! <strong>From here, please follow the steps to formally request a change to the OMOP Common Data Model.</strong></p>
+<p>Great, so you have a network use case and an existing OMOP
+Vocabulary! <strong>From here, please follow the steps to formally
+request a change to the OMOP Common Data Model.</strong></p>
 <p><a href="cdmRequestProcess.html">CDM Request Process</a></p>
 
 
diff --git a/docs/vocabulary.html b/docs/vocabulary.html
index c3a7195b..cd855f14 100644
--- a/docs/vocabulary.html
+++ b/docs/vocabulary.html
@@ -13,7 +13,7 @@
 
 <title>How the Vocabulary is Built</title>
 
-<script src="site_libs/header-attrs-2.13/header-attrs.js"></script>
+<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
 <script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
@@ -148,11 +148,15 @@
     href = "index.html";
   var menuAnchor = $('a[href="' + href + '"]');
 
-  // mark it active
-  menuAnchor.tab('show');
-
-  // if it's got a parent navbar menu mark it active as well
-  menuAnchor.closest('li.dropdown').addClass('active');
+  // mark the anchor link active (and if it's in a dropdown, also mark that active)
+  var dropdown = menuAnchor.closest('li.dropdown');
+  if (window.bootstrap) { // Bootstrap 4+
+    menuAnchor.addClass('active');
+    dropdown.find('> .dropdown-toggle').addClass('active');
+  } else { // Bootstrap 3
+    menuAnchor.parent().addClass('active');
+    dropdown.addClass('active');
+  }
 
   // Navbar adjustments
   var navHeight = $(".navbar").first().height() + 15;
@@ -327,7 +331,7 @@
       <ul class="nav navbar-nav">
         <li>
   <a href="index.html">
-    <span class="fa fa-home"></span>
+    <span class="fa fa-house"></span>
      
   </a>
 </li>
@@ -494,7 +498,16 @@ <h1 class="title toc-ignore">How the Vocabulary is Built</h1>
 
 <div id="mapping-of-concepts" class="section level1">
 <h1>Mapping of Concepts</h1>
-<p><strong>Mapping</strong>, also known as <strong>a map</strong>, is an association between a particular concept in one code system or dataset and code in another, rarely the same, code system that has the same (or similar) meaning. Also, <strong>Mapping</strong> is the process to transform one concept into a Standard one. The Standardized Clinical Data Tables allow only Standard Concepts, thus all other codes used in the source databases have to be translated to Standard Concepts. Mapping is done through records in the CONCEPT_RELATIONSHIP table. They connect each Concept to a Standard Concept through a number of special RELATIONSHIP_IDs:</p>
+<p><strong>Mapping</strong>, also known as <strong>a map</strong>, is an
+association between a particular concept in one code system or dataset
+and code in another, rarely the same, code system that has the same (or
+similar) meaning. Also, <strong>Mapping</strong> is the process to
+transform one concept into a Standard one. The Standardized Clinical
+Data Tables allow only Standard Concepts, thus all other codes used in
+the source databases have to be translated to Standard Concepts. Mapping
+is done through records in the CONCEPT_RELATIONSHIP table. They connect
+each Concept to a Standard Concept through a number of special
+RELATIONSHIP_IDs:</p>
 <table>
 <colgroup>
 <col width="16%" />
@@ -511,31 +524,68 @@ <h1>Mapping of Concepts</h1>
 <tbody>
 <tr class="odd">
 <td><strong>Maps to</strong></td>
-<td>Mapping a Source Concept to a Standard Concept to be placed into the following fields of Standardized Clinical Data Tables <br> <strong>condition_concept_id</strong><br> <strong>observation_concept_id</strong><br><strong>measurement_concept_id</strong><br><strong>drug_concept_id</strong><br><strong>procedure_concept_id</strong><br><strong>device_concept_id</strong> Note, that this relationship is also used for mapping of concepts to populate <strong>value_as_concept_id</strong></td>
-<td>- Stands for either a full equivalence or an “uphill” mapping (mapping to a more general semantic category)<br><br>- Can be single or multiple for each Source Concept</td>
+<td>Mapping a Source Concept to a Standard Concept to be placed into the
+following fields of Standardized Clinical Data Tables <br>
+<strong>condition_concept_id</strong><br>
+<strong>observation_concept_id</strong><br><strong>measurement_concept_id</strong><br><strong>drug_concept_id</strong><br><strong>procedure_concept_id</strong><br><strong>device_concept_id</strong>
+Note, that this relationship is also used for mapping of concepts to
+populate <strong>value_as_concept_id</strong></td>
+<td>- Stands for either a full equivalence or an “uphill” mapping
+(mapping to a more general semantic category)<br><br>- Can be single or
+multiple for each Source Concept</td>
 </tr>
 <tr class="even">
 <td><strong>Maps to value</strong></td>
-<td>A special mapping between a Source Concept and a Standard Concept to be placed into the <strong>value_as_concept_id</strong> field of the MEASUREMENT and OBSERVATION tables</td>
-<td>- Points to a concept, indicating the value of Measurements or content of Observations<br><br> - Is used only in combination with a single “Maps to”</td>
+<td>A special mapping between a Source Concept and a Standard Concept to
+be placed into the <strong>value_as_concept_id</strong> field of the
+MEASUREMENT and OBSERVATION tables</td>
+<td>- Points to a concept, indicating the value of Measurements or
+content of Observations<br><br> - Is used only in combination with a
+single “Maps to”</td>
 </tr>
 </tbody>
 </table>
 <div id="maps-to-relationships" class="section level2">
 <h2>“Maps to” Relationships</h2>
 <ul>
-<li>Concepts participating in the “Maps to” mapping are Source (Non-standard) Concepts and Standard Concepts.</li>
-<li>The mapping always attempts to reflect the semantics of a Source Concept by an Equivalent Standard Concept.</li>
-<li>Equivalent carries the same meaning, covers the same semantic space, and, importantly, has the same parents and children in the hierarchy (if there are any) as well. If an equivalent Concept is not available, the mapping matches to a more generic Standard Concept(s). This ensures that a query in the target vocabulary will retrieve the same records as if they were queried in the original source vocabulary.</li>
-<li>Source Concepts are mapped or may be mapped to one or several Standard Concepts. If they are mapped to more than one Standard Concept, in the resulting CDM table, there is more than one record for each record in the source.</li>
-<li>Standard Concepts are also mapped to Standard Concepts via “Maps to”, this is a mapping to itself.</li>
-<li>If there are 2 or more similar Standard concepts in the OMOP vocabulary, please, report about it at the <a href="https://forums.ohdsi.org/c/vocabulary-users">OHDSI Forum</a> and unless it is fixed, as the first-line choice, use LOINC for Measurements and SNOMED for everything else.</li>
-<li>If there are 2 similar Standard concepts within SNOMED, look at the domain (Morphologic abnormality is an Observation, Clinical finding is a Condition), revise attributes and hierarchy of both concepts (its number, fullness, and correctness). It is not necessary to compare the amount of relationships/children precisely, just verify that all seems appropriate and the hierarchy is rich enough. If it does for both concepts, then choose concepts belonging to SNOMED International (short concept codes) rather than SNOMED US/UK Editions (long concept codes). If the length of concept codes is identical, then choose the one with a smaller number of concept_id.</li>
+<li>Concepts participating in the “Maps to” mapping are Source
+(Non-standard) Concepts and Standard Concepts.</li>
+<li>The mapping always attempts to reflect the semantics of a Source
+Concept by an Equivalent Standard Concept.</li>
+<li>Equivalent carries the same meaning, covers the same semantic space,
+and, importantly, has the same parents and children in the hierarchy (if
+there are any) as well. If an equivalent Concept is not available, the
+mapping matches to a more generic Standard Concept(s). This ensures that
+a query in the target vocabulary will retrieve the same records as if
+they were queried in the original source vocabulary.</li>
+<li>Source Concepts are mapped or may be mapped to one or several
+Standard Concepts. If they are mapped to more than one Standard Concept,
+in the resulting CDM table, there is more than one record for each
+record in the source.</li>
+<li>Standard Concepts are also mapped to Standard Concepts via “Maps
+to”, this is a mapping to itself.</li>
+<li>If there are 2 or more similar Standard concepts in the OMOP
+vocabulary, please, report about it at the <a
+href="https://forums.ohdsi.org/c/vocabulary-users">OHDSI Forum</a> and
+unless it is fixed, as the first-line choice, use LOINC for Measurements
+and SNOMED for everything else.</li>
+<li>If there are 2 similar Standard concepts within SNOMED, look at the
+domain (Morphologic abnormality is an Observation, Clinical finding is a
+Condition), revise attributes and hierarchy of both concepts (its
+number, fullness, and correctness). It is not necessary to compare the
+amount of relationships/children precisely, just verify that all seems
+appropriate and the hierarchy is rich enough. If it does for both
+concepts, then choose concepts belonging to SNOMED International (short
+concept codes) rather than SNOMED US/UK Editions (long concept codes).
+If the length of concept codes is identical, then choose the one with a
+smaller number of concept_id.</li>
 </ul>
-<p><strong>Note!</strong> Classification Concepts (standard_concept=‘C’) do not have a mapping to a Standard Concept.</p>
+<p><strong>Note!</strong> Classification Concepts (standard_concept=‘C’)
+do not have a mapping to a Standard Concept.</p>
 <div id="examples-of-usage" class="section level3">
 <h3>Examples of usage:</h3>
-<p><strong>Single “Maps to” for mapping to an Equivalent Standard Concept</strong></p>
+<p><strong>Single “Maps to” for mapping to an Equivalent Standard
+Concept</strong></p>
 <table>
 <colgroup>
 <col width="13%" />
@@ -574,7 +624,8 @@ <h3>Examples of usage:</h3>
 </tr>
 </tbody>
 </table>
-<p><strong>Single “Maps to” for mapping to a Non-equivalent Standard Concept</strong></p>
+<p><strong>Single “Maps to” for mapping to a Non-equivalent Standard
+Concept</strong></p>
 <table>
 <colgroup>
 <col width="13%" />
@@ -613,7 +664,8 @@ <h3>Examples of usage:</h3>
 </tr>
 </tbody>
 </table>
-<p><strong>Multiple “Maps to” for mapping to several Standard Concepts fully covering semantic space of a Source Concept</strong></p>
+<p><strong>Multiple “Maps to” for mapping to several Standard Concepts
+fully covering semantic space of a Source Concept</strong></p>
 <table>
 <colgroup>
 <col width="13%" />
@@ -684,7 +736,8 @@ <h3>Examples of usage:</h3>
 </tr>
 </tbody>
 </table>
-<p><strong>Multiple “Maps to” for mapping to several Standard Concepts partially covering semantic space of a Source Concept</strong></p>
+<p><strong>Multiple “Maps to” for mapping to several Standard Concepts
+partially covering semantic space of a Source Concept</strong></p>
 <table>
 <colgroup>
 <col width="13%" />
@@ -707,11 +760,13 @@ <h3>Examples of usage:</h3>
 <tbody>
 <tr class="odd">
 <td>V01.11</td>
-<td>Pedestrian on roller-skates injured in collision with pedal cycle in traffic accident</td>
+<td>Pedestrian on roller-skates injured in collision with pedal cycle in
+traffic accident</td>
 <td>Maps to</td>
 <td>442247</td>
 <td>215142005</td>
-<td>Pedal cycle accident involving collision between pedal cycle and pedestrian, pedestrian injured</td>
+<td>Pedal cycle accident involving collision between pedal cycle and
+pedestrian, pedestrian injured</td>
 </tr>
 <tr class="even">
 <td></td>
@@ -723,7 +778,8 @@ <h3>Examples of usage:</h3>
 </tr>
 <tr class="odd">
 <td>T36.1x4</td>
-<td>Poisoning by cephalosporins and other beta-lactam antibiotics, undetermined</td>
+<td>Poisoning by cephalosporins and other beta-lactam antibiotics,
+undetermined</td>
 <td>Maps to</td>
 <td>4303975</td>
 <td>419347003</td>
@@ -743,7 +799,11 @@ <h3>Examples of usage:</h3>
 </div>
 <div id="maps-to-value-relationships" class="section level2">
 <h2>“Maps to value” Relationships</h2>
-<p>To preserve the meaning of Source concepts indicating values of Measurements or content of Observations, “Maps to” are complemented with a comprehensive set of “Maps to value” relationships. Such mappings are considered to be equivalent. There are the following semantic groups of Source concepts which are mapped in such a way:</p>
+<p>To preserve the meaning of Source concepts indicating values of
+Measurements or content of Observations, “Maps to” are complemented with
+a comprehensive set of “Maps to value” relationships. Such mappings are
+considered to be equivalent. There are the following semantic groups of
+Source concepts which are mapped in such a way:</p>
 <ul>
 <li>Conditions indicating abnormal levels of tests</li>
 <li>Encounter for a procedure and an aftercare</li>
@@ -799,7 +859,8 @@ <h2>“Maps to value” Relationships</h2>
 <tr class="odd">
 <td>2</td>
 <td>Z47.0</td>
-<td>Follow-up care involving removal of fracture plate and other internal fixation device</td>
+<td>Follow-up care involving removal of fracture plate and other
+internal fixation device</td>
 <td>Maps to</td>
 <td>390906007</td>
 <td>Follow-up encounter</td>
@@ -889,7 +950,8 @@ <h2>“Maps to value” Relationships</h2>
 <tr class="odd">
 <td>7</td>
 <td>Z92.2</td>
-<td>Personal history of long-term (current) use of other medicaments</td>
+<td>Personal history of long-term (current) use of other
+medicaments</td>
 <td>Maps to</td>
 <td>416940007</td>
 <td>Past history of procedure</td>
@@ -925,7 +987,8 @@ <h2>“Maps to value” Relationships</h2>
 <tr class="odd">
 <td>9</td>
 <td>Z53.2</td>
-<td>Procedure not carried out because of patient’s decision for other and unspecified reasons</td>
+<td>Procedure not carried out because of patient’s decision for other
+and unspecified reasons</td>
 <td>Maps to</td>
 <td>416237000</td>
 <td>Procedure not done</td>
@@ -945,13 +1008,28 @@ <h2>“Maps to value” Relationships</h2>
 </div>
 <div id="losses-in-mapping" class="section level2">
 <h2>“Losses” in Mapping</h2>
-<p><strong>1. The hierarchical discrepancy between Source and Standard Vocabularies</strong></p>
-<p>It is not uncommon for heavily pre-coordinated Concepts (complex and fine-grained Concepts that are combinations of different dimensions). The coordination depends on the structure of the topology of the vocabularies from and to which the Concept is mapped. If they are not equivalent, no direct mapping can be established. But in order to maintain the ability to retrieve these Concepts when searching using hierarchical Concepts, two or more mappings are provided instead.</p>
-<p>For example, in ICD-10-CM diabetic complications are a part of the disorder of Diabetes Mellitus, while in SNOMED Diabetes Mellitus and its complications reside in distinct hierarchical branches.</p>
+<p><strong>1. The hierarchical discrepancy between Source and Standard
+Vocabularies</strong></p>
+<p>It is not uncommon for heavily pre-coordinated Concepts (complex and
+fine-grained Concepts that are combinations of different dimensions).
+The coordination depends on the structure of the topology of the
+vocabularies from and to which the Concept is mapped. If they are not
+equivalent, no direct mapping can be established. But in order to
+maintain the ability to retrieve these Concepts when searching using
+hierarchical Concepts, two or more mappings are provided instead.</p>
+<p>For example, in ICD-10-CM diabetic complications are a part of the
+disorder of Diabetes Mellitus, while in SNOMED Diabetes Mellitus and its
+complications reside in distinct hierarchical branches.</p>
 <p><img src="images/diabetes-related_case.png" /></p>
-<p>As another example, ICD-10 codes indicating complications of pregnancy are in the chapter of “Pregnancy, childbirth and the puerperium” that has a semantic relation to the fact of pregnancy, while in SNOMED denoting pregnancy conditions and their complications are in the separate hierarchical branches.</p>
+<p>As another example, ICD-10 codes indicating complications of
+pregnancy are in the chapter of “Pregnancy, childbirth and the
+puerperium” that has a semantic relation to the fact of pregnancy, while
+in SNOMED denoting pregnancy conditions and their complications are in
+the separate hierarchical branches.</p>
 <p><img src="images/pregnancy-related_case.png" /></p>
-<p>The solution for both examples is to map Non-standard concepts to several standard ones. Even though there is no distinct equivalent in SNOMED, hierarchical queries will retrieve the correct records.</p>
+<p>The solution for both examples is to map Non-standard concepts to
+several standard ones. Even though there is no distinct equivalent in
+SNOMED, hierarchical queries will retrieve the correct records.</p>
 <p><strong>2. Missing Source Concept equivalent</strong></p>
 <p>This is possible due to the following reasons:</p>
 <p><strong>Vague formulation of a Source Concept</strong></p>
@@ -1032,7 +1110,8 @@ <h2>“Losses” in Mapping</h2>
 </tr>
 <tr class="odd">
 <td>S06.4x9</td>
-<td>Epidural hemorrhage with loss of consciousness of unspecified duration</td>
+<td>Epidural hemorrhage with loss of consciousness of unspecified
+duration</td>
 <td>Maps to</td>
 <td>4306943</td>
 <td>82999001</td>
@@ -1064,7 +1143,8 @@ <h2>“Losses” in Mapping</h2>
 </tr>
 </tbody>
 </table>
-<p><strong>Classification difference between Source and Standard Vocabularies</strong></p>
+<p><strong>Classification difference between Source and Standard
+Vocabularies</strong></p>
 <table style="width:100%;">
 <colgroup>
 <col width="12%" />
@@ -1121,38 +1201,136 @@ <h2>“Losses” in Mapping</h2>
 </table>
 <p><strong>Other possible issues that one could encounter:</strong></p>
 <ul>
-<li>Mapping has to exist and it can be built, but it is missing. Please report to <a href="https://forums.ohdsi.org/">the OHDSI Forum</a>, so it can be added.</li>
-<li>Code irrelevant to the patient, for example, ICD-9-CM V65 “Other persons seeking consultation”</li>
-<li>Source code is ill-defined, for example, ICD-9-CM 799 “Other ill-defined and unknown causes of morbidity and mortality”</li>
+<li>Mapping has to exist and it can be built, but it is missing. Please
+report to <a href="https://forums.ohdsi.org/">the OHDSI Forum</a>, so it
+can be added.</li>
+<li>Code irrelevant to the patient, for example, ICD-9-CM V65 “Other
+persons seeking consultation”</li>
+<li>Source code is ill-defined, for example, ICD-9-CM 799 “Other
+ill-defined and unknown causes of morbidity and mortality”</li>
 </ul>
 </div>
 <div id="rules-for-condition-mapping" class="section level2">
 <h2>RULES FOR CONDITION MAPPING</h2>
-<p>In general, Conditions are records suggesting the presence of a disease or medical condition stated as a diagnosis, a sign or a symptom. However, there are a lot of conditions that are not originating in the biological function of the human body but still require medical attention. Or they are true Conditions, but not at the time of the recording (History of) or in the person itself (Family history of). The mapping rules for these are as follows:</p>
-<p><strong>Aftercare after procedures.</strong> Those are mapped to a single concept 413467001 “Aftercare”, and with a second “Maps to value” relationship to the adequate procedure. For example, ICD10CM Z47.1 “Aftercare following joint replacement surgery” maps to both 413467001 “Aftercare” and to the procedure 4189532 “Implantation of joint prosthesis”. Note that “Aftercare” is itself not a condition, but belongs to the Observation Domain.</p>
-<p><strong>Late effects or sequelae of other conditions.</strong> If possible, these are mapped to single concepts describing them as such late effects. For example, ICD10CM S82.874S concept_id 45589204 “Nondisplaced pilon fracture of right tibia, sequela” is mapped to 197150 “Late effect of fracture of lower extremities”. The Domain is Condition.</p>
-<p><strong>History of a condition.</strong> These are conditions, but not at the time of the condition_start_date. Therefore, they are mapped to the Concept 4214956 “History of clinical finding in subject”, which is in the Observation Domain. The condition itself is recorded through the “Maps to value” relationship. For example, ICD10CM Z87.820 concept_id “Personal history of traumatic brain injury” maps to 4214956 “History of clinical finding in subject” and with “Maps to value” 4132546 “Traumatic brain injury”.</p>
-<p><strong>Family history of a condition.</strong> These, too, have a dual mapping to 4167217 “Family history of clinical finding” and a to the actual condition through a “Maps to value” relationship. For example, ICD10/ICD10CM Z80.0 concept_id 45542462 “Family history of malignant neoplasm of digestive organs” maps to 4167217 “Family history of clinical finding” as well as 443568 “Malignant neoplasm of the gastrointestinal tract”.</p>
-<p><strong>History of medical treatment.</strong> Similarly, these are mapped to Observation Concept 4207283 “History of drug therapy”, and through a “Maps to value” link to the actual therapy. For example, ICD10 Z92.0 concept_id 45605174 “Personal history of contraception” goes to 4207283 “History of drug therapy” history of drug therapy and 4027509 “Contraception”. If the exact Ingredient or Clinical/Branded Drug is known, the map would direct to these Drug Concepts. But that is not typical.</p>
-<p><strong>Adverse effect of medication.</strong> If possible, these are mapped to a direct equivalent. However, that usually does not exist, and then they are treated as the above history of medical treatments. For example, both ICD10CM T36.8X5A concept_id 45551127 “Adverse effect of other systemic antibiotics, initial encounter” and T36.8X5D “Adverse effect of other systemic antibiotics, subsequent encounter” map to 437191 “Antibacterial drug adverse reaction”, while ICD10CM T36.8X5S concept_id 45560654 “Adverse effect of other systemic antibiotics, sequela” maps to 4207283 “History of drug therapy”.</p>
-<p><strong>Underdosing of medication.</strong> This information is handled similarly to the adverse effects, and the equivalent SNOMED concepts generally do not exist. For example, ICD10CM T36.0X6A concept_id 45565479 “Underdosing of penicillins, initial encounter” and T36.0X6D concept_id 45565480 “Underdosing of penicillins, subsequent encounter” go to 40488434 “Medication dose too low”, while T36.0X6S concept_id 45565481 “Underdosing of penicillins, sequela” points at 4207283 “History of drug therapy”.</p>
-<p><strong>Status of organ absence or transplant/prosthetic presence.</strong> Absent organs are due to a procedure having removed them (unless they are inborn conditions, which are mapped as such). Therefore, they are mapped to 4215685 “Past history of procedure” and the appropriate procedure that removed the organ through a “Maps to value” link. For example, ICD10CM Z94.0 concept_id 35225404 “Kidney transplant status” maps to 4215685 “Past history of procedure” and 4322471 “Transplant of kidney”. Z95.5 concept_id 35225418 “Presence of coronary angioplasty implant and graft” is pointed to 4215685 “Past history of procedure” and 4184832 “Coronary angioplasty”.</p>
-<p><strong>Pre-coordinated Concepts listing two or more semantic components through AND or OR.</strong> These concepts are treated with the following order of precedence:</p>
+<p>In general, Conditions are records suggesting the presence of a
+disease or medical condition stated as a diagnosis, a sign or a symptom.
+However, there are a lot of conditions that are not originating in the
+biological function of the human body but still require medical
+attention. Or they are true Conditions, but not at the time of the
+recording (History of) or in the person itself (Family history of). The
+mapping rules for these are as follows:</p>
+<p><strong>Aftercare after procedures.</strong> Those are mapped to a
+single concept 413467001 “Aftercare”, and with a second “Maps to value”
+relationship to the adequate procedure. For example, ICD10CM Z47.1
+“Aftercare following joint replacement surgery” maps to both 413467001
+“Aftercare” and to the procedure 4189532 “Implantation of joint
+prosthesis”. Note that “Aftercare” is itself not a condition, but
+belongs to the Observation Domain.</p>
+<p><strong>Late effects or sequelae of other conditions.</strong> If
+possible, these are mapped to single concepts describing them as such
+late effects. For example, ICD10CM S82.874S concept_id 45589204
+“Nondisplaced pilon fracture of right tibia, sequela” is mapped to
+197150 “Late effect of fracture of lower extremities”. The Domain is
+Condition.</p>
+<p><strong>History of a condition.</strong> These are conditions, but
+not at the time of the condition_start_date. Therefore, they are mapped
+to the Concept 4214956 “History of clinical finding in subject”, which
+is in the Observation Domain. The condition itself is recorded through
+the “Maps to value” relationship. For example, ICD10CM Z87.820
+concept_id “Personal history of traumatic brain injury” maps to 4214956
+“History of clinical finding in subject” and with “Maps to value”
+4132546 “Traumatic brain injury”.</p>
+<p><strong>Family history of a condition.</strong> These, too, have a
+dual mapping to 4167217 “Family history of clinical finding” and a to
+the actual condition through a “Maps to value” relationship. For
+example, ICD10/ICD10CM Z80.0 concept_id 45542462 “Family history of
+malignant neoplasm of digestive organs” maps to 4167217 “Family history
+of clinical finding” as well as 443568 “Malignant neoplasm of the
+gastrointestinal tract”.</p>
+<p><strong>History of medical treatment.</strong> Similarly, these are
+mapped to Observation Concept 4207283 “History of drug therapy”, and
+through a “Maps to value” link to the actual therapy. For example, ICD10
+Z92.0 concept_id 45605174 “Personal history of contraception” goes to
+4207283 “History of drug therapy” history of drug therapy and 4027509
+“Contraception”. If the exact Ingredient or Clinical/Branded Drug is
+known, the map would direct to these Drug Concepts. But that is not
+typical.</p>
+<p><strong>Adverse effect of medication.</strong> If possible, these are
+mapped to a direct equivalent. However, that usually does not exist, and
+then they are treated as the above history of medical treatments. For
+example, both ICD10CM T36.8X5A concept_id 45551127 “Adverse effect of
+other systemic antibiotics, initial encounter” and T36.8X5D “Adverse
+effect of other systemic antibiotics, subsequent encounter” map to
+437191 “Antibacterial drug adverse reaction”, while ICD10CM T36.8X5S
+concept_id 45560654 “Adverse effect of other systemic antibiotics,
+sequela” maps to 4207283 “History of drug therapy”.</p>
+<p><strong>Underdosing of medication.</strong> This information is
+handled similarly to the adverse effects, and the equivalent SNOMED
+concepts generally do not exist. For example, ICD10CM T36.0X6A
+concept_id 45565479 “Underdosing of penicillins, initial encounter” and
+T36.0X6D concept_id 45565480 “Underdosing of penicillins, subsequent
+encounter” go to 40488434 “Medication dose too low”, while T36.0X6S
+concept_id 45565481 “Underdosing of penicillins, sequela” points at
+4207283 “History of drug therapy”.</p>
+<p><strong>Status of organ absence or transplant/prosthetic
+presence.</strong> Absent organs are due to a procedure having removed
+them (unless they are inborn conditions, which are mapped as such).
+Therefore, they are mapped to 4215685 “Past history of procedure” and
+the appropriate procedure that removed the organ through a “Maps to
+value” link. For example, ICD10CM Z94.0 concept_id 35225404 “Kidney
+transplant status” maps to 4215685 “Past history of procedure” and
+4322471 “Transplant of kidney”. Z95.5 concept_id 35225418 “Presence of
+coronary angioplasty implant and graft” is pointed to 4215685 “Past
+history of procedure” and 4184832 “Coronary angioplasty”.</p>
+<p><strong>Pre-coordinated Concepts listing two or more semantic
+components through AND or OR.</strong> These concepts are treated with
+the following order of precedence:</p>
 <ul>
-<li>To an equivalent combination concept that is also hierarchically well connected</li>
+<li>To an equivalent combination concept that is also hierarchically
+well connected</li>
 <li>To both components separately</li>
 <li>To the most common ancestor</li>
 </ul>
 <p>Examples for these 3 possibilities are:</p>
 <ul>
-<li>ICD10 A01 concept_id 45576225 “Typhoid and paratyphoid fevers” has a single “Maps to” relationship to 4022808 “Human typhoid AND/OR paratyphoid fever”.</li>
-<li>IC10CM F12.22 concept_id 45591098 “Cannabis dependence with intoxication” has two “Maps to” relationships to 4052690 “Cannabis intoxication” and 440387 “Cannabis dependence”.</li>
-<li>ICD10 L02.0 concept_id 45596354 “Cutaneous abscess, furuncle and carbuncle of face” has a single “Maps to” relationship_id to 400082007 Disorder of skin of head.</li>
+<li>ICD10 A01 concept_id 45576225 “Typhoid and paratyphoid fevers” has a
+single “Maps to” relationship to 4022808 “Human typhoid AND/OR
+paratyphoid fever”.</li>
+<li>IC10CM F12.22 concept_id 45591098 “Cannabis dependence with
+intoxication” has two “Maps to” relationships to 4052690 “Cannabis
+intoxication” and 440387 “Cannabis dependence”.</li>
+<li>ICD10 L02.0 concept_id 45596354 “Cutaneous abscess, furuncle and
+carbuncle of face” has a single “Maps to” relationship_id to 400082007
+Disorder of skin of head.</li>
 </ul>
-<p><strong>Maternal care.</strong> Many conditions require attention not because of a condition of a pregnant woman but of the fetus. However, all such conditions are being mapped to the mother anyway. For example, ICD10 O35.6 concept_id 45567927 “Maternal care for (suspected) damage to fetus by radiation” has two “Maps to” relationships to 199553006 “Fetus with radiation damage” and 289908002 “pregnancy”. Both conditions are recorded with the mother.</p>
-<p><strong>Need for immunization.</strong> These Concepts are mapped to an Observation indicating such an immunity gap. A second mapping with the relationship_id “Maps to value” is then directed to the Condition (represented as a SNOMED Concept) the immunization is inoculating against. Note that it is not mapped to the vaccine itself (which would be represented as a RxNorm Concept). For example, ICD10 Z23 concept_id 45556822 “Need for immunization against single bacterial diseases” maps to 170536002 “Vaccination required” and maps to value 87628006 “Bacterial infectious disease”.</p>
-<p><strong>Conditions indicating abnormal levels of a test.</strong> These are split into the Measurement and result Concepts. For example, ICD10 R77.1 concept_id 45553745 “Abnormality of globulin” has a “Maps to” relationship to the Measurement 4353510 “Globulin measurement” and a “Maps to value” relationship to 4135493 “Abnormal”.</p>
-<p><strong>Conditions resulting from the use of Devices.</strong> Adverse or other outcomes of the exposure to a device are mapped to 473023007 “Complication associated with device and with another”Maps to value" relationship to the device itself, if possible. For example, ICD10 Y73.0 concept_id 45590664 “Gastroenterology and urology devices associated with adverse incidents, diagnostic and monitoring devices” has a “Maps to value” link to 45767866 “Gastro-urological device”.</p>
+<p><strong>Maternal care.</strong> Many conditions require attention not
+because of a condition of a pregnant woman but of the fetus. However,
+all such conditions are being mapped to the mother anyway. For example,
+ICD10 O35.6 concept_id 45567927 “Maternal care for (suspected) damage to
+fetus by radiation” has two “Maps to” relationships to 199553006 “Fetus
+with radiation damage” and 289908002 “pregnancy”. Both conditions are
+recorded with the mother.</p>
+<p><strong>Need for immunization.</strong> These Concepts are mapped to
+an Observation indicating such an immunity gap. A second mapping with
+the relationship_id “Maps to value” is then directed to the Condition
+(represented as a SNOMED Concept) the immunization is inoculating
+against. Note that it is not mapped to the vaccine itself (which would
+be represented as a RxNorm Concept). For example, ICD10 Z23 concept_id
+45556822 “Need for immunization against single bacterial diseases” maps
+to 170536002 “Vaccination required” and maps to value 87628006
+“Bacterial infectious disease”.</p>
+<p><strong>Conditions indicating abnormal levels of a test.</strong>
+These are split into the Measurement and result Concepts. For example,
+ICD10 R77.1 concept_id 45553745 “Abnormality of globulin” has a “Maps
+to” relationship to the Measurement 4353510 “Globulin measurement” and a
+“Maps to value” relationship to 4135493 “Abnormal”.</p>
+<p><strong>Conditions resulting from the use of Devices.</strong>
+Adverse or other outcomes of the exposure to a device are mapped to
+473023007 “Complication associated with device and with another”Maps to
+value” relationship to the device itself, if possible. For example,
+ICD10 Y73.0 concept_id 45590664 “Gastroenterology and urology devices
+associated with adverse incidents, diagnostic and monitoring devices”
+has a “Maps to value” link to 45767866 “Gastro-urological device”.</p>
 </div>
 <div id="condition-mapping-algorithm" class="section level2">
 <h2>CONDITION MAPPING ALGORITHM</h2>
diff --git a/extras/codeToRun.R b/extras/codeToRun.R
index c4bfb3f9..e50bd940 100644
--- a/extras/codeToRun.R
+++ b/extras/codeToRun.R
@@ -22,12 +22,12 @@ for (cdmVersion in supportedVersions) {
   }
 }
 
-CommonDataModel::buildRelease("5.3")
+CommonDataModel::buildRelease("5.4")
 
 #############
 # Zipping release
 # All dialects
-CommonDataModel::buildReleaseZip(cdmVersion="5.3", outputfolder="output")
+CommonDataModel::buildReleaseZip(cdmVersion="5.4", outputfolder="output")
 
 buildReleaseZip()
 
@@ -38,7 +38,7 @@ buildReleaseZip(cdmVersion="5.4", targetDialect="postgresql", outputfolder="outp
 # BE SURE TO RUN THE EXTRAS/SITEMAINTENANCE.R BEFORE CREATING THE PDF
 
 # step 9: Run the following code to create the pdf documentation. It will be written to the reports folder. Use knit with pagedown
-pagedown::chrome_print("rmd/cdm531.Rmd") # create a comprehensive rmd with background, conventions, etc like https://stackoverflow.com/questions/25824795/how-to-combine-two-rmarkdown-rmd-files-into-a-single-output
+pagedown::chrome_print("cdm54.Rmd") # create a comprehensive rmd with background, conventions, etc like https://stackoverflow.com/questions/25824795/how-to-combine-two-rmarkdown-rmd-files-into-a-single-output
 
 # Step 10: After updating any of the .Rmd files, rendering the site following directions in SiteMaintenance.R, then move the files to the CommonDataModel directory
 
diff --git a/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_constraints.sql b/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_constraints.sql
index e8518447..3b259fd7 100644
--- a/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_constraints.sql
+++ b/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_constraints.sql
@@ -1,353 +1,177 @@
 --bigquery CDM Foreign Key Constraints for OMOP Common Data Model 5.4
-
 alter table @cdmDatabaseSchema.person add constraint fpk_person_gender_concept_id foreign key (gender_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.person add constraint fpk_person_race_concept_id foreign key (race_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.person add constraint fpk_person_ethnicity_concept_id foreign key (ethnicity_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.person add constraint fpk_person_location_id foreign key (location_id) references @cdmDatabaseSchema.location (location_id);
-
 alter table @cdmDatabaseSchema.person add constraint fpk_person_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.person add constraint fpk_person_care_site_id foreign key (care_site_id) references @cdmDatabaseSchema.care_site (care_site_id);
-
 alter table @cdmDatabaseSchema.person add constraint fpk_person_gender_source_concept_id foreign key (gender_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.person add constraint fpk_person_race_source_concept_id foreign key (race_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.person add constraint fpk_person_ethnicity_source_concept_id foreign key (ethnicity_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.observation_period add constraint fpk_observation_period_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.observation_period add constraint fpk_observation_period_period_type_concept_id foreign key (period_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint fpk_visit_occurrence_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint fpk_visit_occurrence_visit_concept_id foreign key (visit_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint fpk_visit_occurrence_visit_type_concept_id foreign key (visit_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint fpk_visit_occurrence_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint fpk_visit_occurrence_care_site_id foreign key (care_site_id) references @cdmDatabaseSchema.care_site (care_site_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint fpk_visit_occurrence_visit_source_concept_id foreign key (visit_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint fpk_visit_occurrence_admitted_from_concept_id foreign key (admitted_from_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint fpk_visit_occurrence_discharged_to_concept_id foreign key (discharged_to_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint fpk_visit_occurrence_preceding_visit_occurrence_id foreign key (preceding_visit_occurrence_id) references @cdmDatabaseSchema.visit_occurrence (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_visit_detail_concept_id foreign key (visit_detail_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_visit_detail_type_concept_id foreign key (visit_detail_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_care_site_id foreign key (care_site_id) references @cdmDatabaseSchema.care_site (care_site_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_visit_detail_source_concept_id foreign key (visit_detail_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_admitted_from_concept_id foreign key (admitted_from_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_discharged_to_concept_id foreign key (discharged_to_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_preceding_visit_detail_id foreign key (preceding_visit_detail_id) references @cdmDatabaseSchema.visit_detail (visit_detail_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_parent_visit_detail_id foreign key (parent_visit_detail_id) references @cdmDatabaseSchema.visit_detail (visit_detail_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint fpk_visit_detail_visit_occurrence_id foreign key (visit_occurrence_id) references @cdmDatabaseSchema.visit_occurrence (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.condition_occurrence add constraint fpk_condition_occurrence_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.condition_occurrence add constraint fpk_condition_occurrence_condition_concept_id foreign key (condition_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.condition_occurrence add constraint fpk_condition_occurrence_condition_type_concept_id foreign key (condition_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.condition_occurrence add constraint fpk_condition_occurrence_condition_status_concept_id foreign key (condition_status_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.condition_occurrence add constraint fpk_condition_occurrence_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.condition_occurrence add constraint fpk_condition_occurrence_visit_occurrence_id foreign key (visit_occurrence_id) references @cdmDatabaseSchema.visit_occurrence (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.condition_occurrence add constraint fpk_condition_occurrence_visit_detail_id foreign key (visit_detail_id) references @cdmDatabaseSchema.visit_detail (visit_detail_id);
-
 alter table @cdmDatabaseSchema.condition_occurrence add constraint fpk_condition_occurrence_condition_source_concept_id foreign key (condition_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.drug_exposure add constraint fpk_drug_exposure_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.drug_exposure add constraint fpk_drug_exposure_drug_concept_id foreign key (drug_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.drug_exposure add constraint fpk_drug_exposure_drug_type_concept_id foreign key (drug_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.drug_exposure add constraint fpk_drug_exposure_route_concept_id foreign key (route_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.drug_exposure add constraint fpk_drug_exposure_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.drug_exposure add constraint fpk_drug_exposure_visit_occurrence_id foreign key (visit_occurrence_id) references @cdmDatabaseSchema.visit_occurrence (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.drug_exposure add constraint fpk_drug_exposure_visit_detail_id foreign key (visit_detail_id) references @cdmDatabaseSchema.visit_detail (visit_detail_id);
-
 alter table @cdmDatabaseSchema.drug_exposure add constraint fpk_drug_exposure_drug_source_concept_id foreign key (drug_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.procedure_occurrence add constraint fpk_procedure_occurrence_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.procedure_occurrence add constraint fpk_procedure_occurrence_procedure_concept_id foreign key (procedure_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.procedure_occurrence add constraint fpk_procedure_occurrence_procedure_type_concept_id foreign key (procedure_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.procedure_occurrence add constraint fpk_procedure_occurrence_modifier_concept_id foreign key (modifier_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.procedure_occurrence add constraint fpk_procedure_occurrence_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.procedure_occurrence add constraint fpk_procedure_occurrence_visit_occurrence_id foreign key (visit_occurrence_id) references @cdmDatabaseSchema.visit_occurrence (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.procedure_occurrence add constraint fpk_procedure_occurrence_visit_detail_id foreign key (visit_detail_id) references @cdmDatabaseSchema.visit_detail (visit_detail_id);
-
 alter table @cdmDatabaseSchema.procedure_occurrence add constraint fpk_procedure_occurrence_procedure_source_concept_id foreign key (procedure_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint fpk_device_exposure_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint fpk_device_exposure_device_concept_id foreign key (device_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint fpk_device_exposure_device_type_concept_id foreign key (device_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint fpk_device_exposure_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint fpk_device_exposure_visit_occurrence_id foreign key (visit_occurrence_id) references @cdmDatabaseSchema.visit_occurrence (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint fpk_device_exposure_visit_detail_id foreign key (visit_detail_id) references @cdmDatabaseSchema.visit_detail (visit_detail_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint fpk_device_exposure_device_source_concept_id foreign key (device_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint fpk_device_exposure_unit_concept_id foreign key (unit_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint fpk_device_exposure_unit_source_concept_id foreign key (unit_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_measurement_concept_id foreign key (measurement_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_measurement_type_concept_id foreign key (measurement_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_operator_concept_id foreign key (operator_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_value_as_concept_id foreign key (value_as_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_unit_concept_id foreign key (unit_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_visit_occurrence_id foreign key (visit_occurrence_id) references @cdmDatabaseSchema.visit_occurrence (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_visit_detail_id foreign key (visit_detail_id) references @cdmDatabaseSchema.visit_detail (visit_detail_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_measurement_source_concept_id foreign key (measurement_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_unit_source_concept_id foreign key (unit_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint fpk_measurement_meas_event_field_concept_id foreign key (meas_event_field_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_observation_concept_id foreign key (observation_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_observation_type_concept_id foreign key (observation_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_value_as_concept_id foreign key (value_as_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_qualifier_concept_id foreign key (qualifier_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_unit_concept_id foreign key (unit_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_visit_occurrence_id foreign key (visit_occurrence_id) references @cdmDatabaseSchema.visit_occurrence (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_visit_detail_id foreign key (visit_detail_id) references @cdmDatabaseSchema.visit_detail (visit_detail_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_observation_source_concept_id foreign key (observation_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.observation add constraint fpk_observation_obs_event_field_concept_id foreign key (obs_event_field_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.death add constraint fpk_death_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.death add constraint fpk_death_death_type_concept_id foreign key (death_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.death add constraint fpk_death_cause_concept_id foreign key (cause_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.death add constraint fpk_death_cause_source_concept_id foreign key (cause_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.note add constraint fpk_note_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.note add constraint fpk_note_note_type_concept_id foreign key (note_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.note add constraint fpk_note_note_class_concept_id foreign key (note_class_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.note add constraint fpk_note_encoding_concept_id foreign key (encoding_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.note add constraint fpk_note_language_concept_id foreign key (language_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.note add constraint fpk_note_provider_id foreign key (provider_id) references @cdmDatabaseSchema.provider (provider_id);
-
 alter table @cdmDatabaseSchema.note add constraint fpk_note_visit_occurrence_id foreign key (visit_occurrence_id) references @cdmDatabaseSchema.visit_occurrence (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.note add constraint fpk_note_visit_detail_id foreign key (visit_detail_id) references @cdmDatabaseSchema.visit_detail (visit_detail_id);
-
 alter table @cdmDatabaseSchema.note add constraint fpk_note_note_event_field_concept_id foreign key (note_event_field_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.note_nlp add constraint fpk_note_nlp_section_concept_id foreign key (section_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.note_nlp add constraint fpk_note_nlp_note_nlp_concept_id foreign key (note_nlp_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.note_nlp add constraint fpk_note_nlp_note_nlp_source_concept_id foreign key (note_nlp_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.specimen add constraint fpk_specimen_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.specimen add constraint fpk_specimen_specimen_concept_id foreign key (specimen_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.specimen add constraint fpk_specimen_specimen_type_concept_id foreign key (specimen_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.specimen add constraint fpk_specimen_unit_concept_id foreign key (unit_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.specimen add constraint fpk_specimen_anatomic_site_concept_id foreign key (anatomic_site_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.specimen add constraint fpk_specimen_disease_status_concept_id foreign key (disease_status_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.fact_relationship add constraint fpk_fact_relationship_domain_concept_id_1 foreign key (domain_concept_id_1) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.fact_relationship add constraint fpk_fact_relationship_domain_concept_id_2 foreign key (domain_concept_id_2) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.fact_relationship add constraint fpk_fact_relationship_relationship_concept_id foreign key (relationship_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.location add constraint fpk_location_country_concept_id foreign key (country_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.care_site add constraint fpk_care_site_place_of_service_concept_id foreign key (place_of_service_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.care_site add constraint fpk_care_site_location_id foreign key (location_id) references @cdmDatabaseSchema.location (location_id);
-
 alter table @cdmDatabaseSchema.provider add constraint fpk_provider_specialty_concept_id foreign key (specialty_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.provider add constraint fpk_provider_care_site_id foreign key (care_site_id) references @cdmDatabaseSchema.care_site (care_site_id);
-
 alter table @cdmDatabaseSchema.provider add constraint fpk_provider_gender_concept_id foreign key (gender_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.provider add constraint fpk_provider_specialty_source_concept_id foreign key (specialty_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.provider add constraint fpk_provider_gender_source_concept_id foreign key (gender_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint fpk_payer_plan_period_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint fpk_payer_plan_period_payer_concept_id foreign key (payer_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint fpk_payer_plan_period_payer_source_concept_id foreign key (payer_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint fpk_payer_plan_period_plan_concept_id foreign key (plan_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint fpk_payer_plan_period_plan_source_concept_id foreign key (plan_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint fpk_payer_plan_period_sponsor_concept_id foreign key (sponsor_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint fpk_payer_plan_period_sponsor_source_concept_id foreign key (sponsor_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint fpk_payer_plan_period_stop_reason_concept_id foreign key (stop_reason_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint fpk_payer_plan_period_stop_reason_source_concept_id foreign key (stop_reason_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.cost add constraint fpk_cost_cost_domain_id foreign key (cost_domain_id) references @cdmDatabaseSchema.domain (domain_id);
-
 alter table @cdmDatabaseSchema.cost add constraint fpk_cost_cost_type_concept_id foreign key (cost_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.cost add constraint fpk_cost_currency_concept_id foreign key (currency_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.cost add constraint fpk_cost_revenue_code_concept_id foreign key (revenue_code_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.cost add constraint fpk_cost_drg_concept_id foreign key (drg_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.drug_era add constraint fpk_drug_era_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.drug_era add constraint fpk_drug_era_drug_concept_id foreign key (drug_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.dose_era add constraint fpk_dose_era_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.dose_era add constraint fpk_dose_era_drug_concept_id foreign key (drug_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.dose_era add constraint fpk_dose_era_unit_concept_id foreign key (unit_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.condition_era add constraint fpk_condition_era_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.condition_era add constraint fpk_condition_era_condition_concept_id foreign key (condition_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.episode add constraint fpk_episode_person_id foreign key (person_id) references @cdmDatabaseSchema.person (person_id);
-
 alter table @cdmDatabaseSchema.episode add constraint fpk_episode_episode_concept_id foreign key (episode_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.episode add constraint fpk_episode_episode_object_concept_id foreign key (episode_object_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.episode add constraint fpk_episode_episode_type_concept_id foreign key (episode_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.episode add constraint fpk_episode_episode_source_concept_id foreign key (episode_source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.episode_event add constraint fpk_episode_event_episode_id foreign key (episode_id) references @cdmDatabaseSchema.episode (episode_id);
-
 alter table @cdmDatabaseSchema.episode_event add constraint fpk_episode_event_episode_event_field_concept_id foreign key (episode_event_field_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.metadata add constraint fpk_metadata_metadata_concept_id foreign key (metadata_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.metadata add constraint fpk_metadata_metadata_type_concept_id foreign key (metadata_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.metadata add constraint fpk_metadata_value_as_concept_id foreign key (value_as_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.cdm_source add constraint fpk_cdm_source_cdm_version_concept_id foreign key (cdm_version_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.concept add constraint fpk_concept_domain_id foreign key (domain_id) references @cdmDatabaseSchema.domain (domain_id);
-
 alter table @cdmDatabaseSchema.concept add constraint fpk_concept_vocabulary_id foreign key (vocabulary_id) references @cdmDatabaseSchema.vocabulary (vocabulary_id);
-
 alter table @cdmDatabaseSchema.concept add constraint fpk_concept_concept_class_id foreign key (concept_class_id) references @cdmDatabaseSchema.concept_class (concept_class_id);
-
 alter table @cdmDatabaseSchema.vocabulary add constraint fpk_vocabulary_vocabulary_concept_id foreign key (vocabulary_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.domain add constraint fpk_domain_domain_concept_id foreign key (domain_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.concept_class add constraint fpk_concept_class_concept_class_concept_id foreign key (concept_class_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.concept_relationship add constraint fpk_concept_relationship_concept_id_1 foreign key (concept_id_1) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.concept_relationship add constraint fpk_concept_relationship_concept_id_2 foreign key (concept_id_2) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.concept_relationship add constraint fpk_concept_relationship_relationship_id foreign key (relationship_id) references @cdmDatabaseSchema.relationship (relationship_id);
-
 alter table @cdmDatabaseSchema.relationship add constraint fpk_relationship_relationship_concept_id foreign key (relationship_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.concept_synonym add constraint fpk_concept_synonym_concept_id foreign key (concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.concept_synonym add constraint fpk_concept_synonym_language_concept_id foreign key (language_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.concept_ancestor add constraint fpk_concept_ancestor_ancestor_concept_id foreign key (ancestor_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.concept_ancestor add constraint fpk_concept_ancestor_descendant_concept_id foreign key (descendant_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.source_to_concept_map add constraint fpk_source_to_concept_map_source_concept_id foreign key (source_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.source_to_concept_map add constraint fpk_source_to_concept_map_target_concept_id foreign key (target_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.source_to_concept_map add constraint fpk_source_to_concept_map_target_vocabulary_id foreign key (target_vocabulary_id) references @cdmDatabaseSchema.vocabulary (vocabulary_id);
-
 alter table @cdmDatabaseSchema.drug_strength add constraint fpk_drug_strength_drug_concept_id foreign key (drug_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.drug_strength add constraint fpk_drug_strength_ingredient_concept_id foreign key (ingredient_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.drug_strength add constraint fpk_drug_strength_amount_unit_concept_id foreign key (amount_unit_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.drug_strength add constraint fpk_drug_strength_numerator_unit_concept_id foreign key (numerator_unit_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.drug_strength add constraint fpk_drug_strength_denominator_unit_concept_id foreign key (denominator_unit_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.cohort_definition add constraint fpk_cohort_definition_definition_type_concept_id foreign key (definition_type_concept_id) references @cdmDatabaseSchema.concept (concept_id);
-
 alter table @cdmDatabaseSchema.cohort_definition add constraint fpk_cohort_definition_subject_concept_id foreign key (subject_concept_id) references @cdmDatabaseSchema.concept (concept_id);
diff --git a/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_ddl.sql b/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_ddl.sql
index 507f7aee..f90ccf80 100644
--- a/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_ddl.sql
+++ b/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_ddl.sql
@@ -1,5 +1,4 @@
 --bigquery CDM DDL Specification for OMOP Common Data Model 5.4
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.person (
 			person_id INT64 not null,
@@ -7,7 +6,7 @@ create table @cdmDatabaseSchema.person (
 			year_of_birth INT64 not null,
 			month_of_birth INT64,
 			day_of_birth INT64,
-			birth_datetime datetime null,
+			birth_datetime DATETIME,
 			race_concept_id INT64 not null,
 			ethnicity_concept_id INT64 not null,
 			location_id INT64,
@@ -20,7 +19,6 @@ create table @cdmDatabaseSchema.person (
 			race_source_concept_id INT64,
 			ethnicity_source_value STRING,
 			ethnicity_source_concept_id INT64 );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.observation_period (
 			observation_period_id INT64 not null,
@@ -28,16 +26,15 @@ create table @cdmDatabaseSchema.observation_period (
 			observation_period_start_date date not null,
 			observation_period_end_date date not null,
 			period_type_concept_id INT64 not null );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.visit_occurrence (
 			visit_occurrence_id INT64 not null,
 			person_id INT64 not null,
 			visit_concept_id INT64 not null,
 			visit_start_date date not null,
-			visit_start_datetime datetime null,
+			visit_start_datetime DATETIME,
 			visit_end_date date not null,
-			visit_end_datetime datetime null,
+			visit_end_datetime DATETIME,
 			visit_type_concept_id INT64 not null,
 			provider_id INT64,
 			care_site_id INT64,
@@ -48,16 +45,15 @@ create table @cdmDatabaseSchema.visit_occurrence (
 			discharged_to_concept_id INT64,
 			discharged_to_source_value STRING,
 			preceding_visit_occurrence_id INT64 );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.visit_detail (
 			visit_detail_id INT64 not null,
 			person_id INT64 not null,
 			visit_detail_concept_id INT64 not null,
 			visit_detail_start_date date not null,
-			visit_detail_start_datetime datetime null,
+			visit_detail_start_datetime DATETIME,
 			visit_detail_end_date date not null,
-			visit_detail_end_datetime datetime null,
+			visit_detail_end_datetime DATETIME,
 			visit_detail_type_concept_id INT64 not null,
 			provider_id INT64,
 			care_site_id INT64,
@@ -70,16 +66,15 @@ create table @cdmDatabaseSchema.visit_detail (
 			preceding_visit_detail_id INT64,
 			parent_visit_detail_id INT64,
 			visit_occurrence_id INT64 not null );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.condition_occurrence (
 			condition_occurrence_id INT64 not null,
 			person_id INT64 not null,
 			condition_concept_id INT64 not null,
 			condition_start_date date not null,
-			condition_start_datetime datetime null,
-			condition_end_date date null,
-			condition_end_datetime datetime null,
+			condition_start_datetime DATETIME,
+			condition_end_date DATE,
+			condition_end_datetime DATETIME,
 			condition_type_concept_id INT64 not null,
 			condition_status_concept_id INT64,
 			stop_reason STRING,
@@ -89,21 +84,20 @@ create table @cdmDatabaseSchema.condition_occurrence (
 			condition_source_value STRING,
 			condition_source_concept_id INT64,
 			condition_status_source_value STRING );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.drug_exposure (
 			drug_exposure_id INT64 not null,
 			person_id INT64 not null,
 			drug_concept_id INT64 not null,
 			drug_exposure_start_date date not null,
-			drug_exposure_start_datetime datetime null,
+			drug_exposure_start_datetime DATETIME,
 			drug_exposure_end_date date not null,
-			drug_exposure_end_datetime datetime null,
-			verbatim_end_date date null,
+			drug_exposure_end_datetime DATETIME,
+			verbatim_end_date DATE,
 			drug_type_concept_id INT64 not null,
 			stop_reason STRING,
 			refills INT64,
-			quantity FLOAT64 null,
+			quantity FLOAT64,
 			days_supply INT64,
 			sig STRING,
 			route_concept_id INT64,
@@ -115,16 +109,15 @@ create table @cdmDatabaseSchema.drug_exposure (
 			drug_source_concept_id INT64,
 			route_source_value STRING,
 			dose_unit_source_value STRING );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.procedure_occurrence (
 			procedure_occurrence_id INT64 not null,
 			person_id INT64 not null,
 			procedure_concept_id INT64 not null,
 			procedure_date date not null,
-			procedure_datetime datetime null,
-			procedure_end_date date null,
-			procedure_end_datetime datetime null,
+			procedure_datetime DATETIME,
+			procedure_end_date DATE,
+			procedure_end_datetime DATETIME,
 			procedure_type_concept_id INT64 not null,
 			modifier_concept_id INT64,
 			quantity INT64,
@@ -134,16 +127,15 @@ create table @cdmDatabaseSchema.procedure_occurrence (
 			procedure_source_value STRING,
 			procedure_source_concept_id INT64,
 			modifier_source_value STRING );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.device_exposure (
 			device_exposure_id INT64 not null,
 			person_id INT64 not null,
 			device_concept_id INT64 not null,
 			device_exposure_start_date date not null,
-			device_exposure_start_datetime datetime null,
-			device_exposure_end_date date null,
-			device_exposure_end_datetime datetime null,
+			device_exposure_start_datetime DATETIME,
+			device_exposure_end_date DATE,
+			device_exposure_end_datetime DATETIME,
 			device_type_concept_id INT64 not null,
 			unique_device_id STRING,
 			production_id STRING,
@@ -156,22 +148,21 @@ create table @cdmDatabaseSchema.device_exposure (
 			unit_concept_id INT64,
 			unit_source_value STRING,
 			unit_source_concept_id INT64 );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.measurement (
 			measurement_id INT64 not null,
 			person_id INT64 not null,
 			measurement_concept_id INT64 not null,
 			measurement_date date not null,
-			measurement_datetime datetime null,
+			measurement_datetime DATETIME,
 			measurement_time STRING,
 			measurement_type_concept_id INT64 not null,
 			operator_concept_id INT64,
-			value_as_number FLOAT64 null,
+			value_as_number FLOAT64,
 			value_as_concept_id INT64,
 			unit_concept_id INT64,
-			range_low FLOAT64 null,
-			range_high FLOAT64 null,
+			range_low FLOAT64,
+			range_high FLOAT64,
 			provider_id INT64,
 			visit_occurrence_id INT64,
 			visit_detail_id INT64,
@@ -182,16 +173,15 @@ create table @cdmDatabaseSchema.measurement (
 			value_source_value STRING,
 			measurement_event_id INT64,
 			meas_event_field_concept_id INT64 );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.observation (
 			observation_id INT64 not null,
 			person_id INT64 not null,
 			observation_concept_id INT64 not null,
 			observation_date date not null,
-			observation_datetime datetime null,
+			observation_datetime DATETIME,
 			observation_type_concept_id INT64 not null,
-			value_as_number FLOAT64 null,
+			value_as_number FLOAT64,
 			value_as_string STRING,
 			value_as_concept_id INT64,
 			qualifier_concept_id INT64,
@@ -206,23 +196,21 @@ create table @cdmDatabaseSchema.observation (
 			value_source_value STRING,
 			observation_event_id INT64,
 			obs_event_field_concept_id INT64 );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.death (
 			person_id INT64 not null,
 			death_date date not null,
-			death_datetime datetime null,
+			death_datetime DATETIME,
 			death_type_concept_id INT64,
 			cause_concept_id INT64,
 			cause_source_value STRING,
 			cause_source_concept_id INT64 );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.note (
 			note_id INT64 not null,
 			person_id INT64 not null,
 			note_date date not null,
-			note_datetime datetime null,
+			note_datetime DATETIME,
 			note_type_concept_id INT64 not null,
 			note_class_concept_id INT64 not null,
 			note_title STRING,
@@ -235,7 +223,6 @@ create table @cdmDatabaseSchema.note (
 			note_source_value STRING,
 			note_event_id INT64,
 			note_event_field_concept_id INT64 );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.note_nlp (
 			note_nlp_id INT64 not null,
@@ -248,11 +235,10 @@ create table @cdmDatabaseSchema.note_nlp (
 			note_nlp_source_concept_id INT64,
 			nlp_system STRING,
 			nlp_date date not null,
-			nlp_datetime datetime null,
+			nlp_datetime DATETIME,
 			term_exists STRING,
 			term_temporal STRING,
 			term_modifiers STRING );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.specimen (
 			specimen_id INT64 not null,
@@ -260,8 +246,8 @@ create table @cdmDatabaseSchema.specimen (
 			specimen_concept_id INT64 not null,
 			specimen_type_concept_id INT64 not null,
 			specimen_date date not null,
-			specimen_datetime datetime null,
-			quantity FLOAT64 null,
+			specimen_datetime DATETIME,
+			quantity FLOAT64,
 			unit_concept_id INT64,
 			anatomic_site_concept_id INT64,
 			disease_status_concept_id INT64,
@@ -270,7 +256,6 @@ create table @cdmDatabaseSchema.specimen (
 			unit_source_value STRING,
 			anatomic_site_source_value STRING,
 			disease_status_source_value STRING );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.fact_relationship (
 			domain_concept_id_1 INT64 not null,
@@ -278,7 +263,6 @@ create table @cdmDatabaseSchema.fact_relationship (
 			domain_concept_id_2 INT64 not null,
 			fact_id_2 INT64 not null,
 			relationship_concept_id INT64 not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.location (
 			location_id INT64 not null,
@@ -291,9 +275,8 @@ create table @cdmDatabaseSchema.location (
 			location_source_value STRING,
 			country_concept_id INT64,
 			country_source_value STRING,
-			latitude FLOAT64 null,
-			longitude FLOAT64 null );
-
+			latitude FLOAT64,
+			longitude FLOAT64 );
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.care_site (
 			care_site_id INT64 not null,
@@ -302,7 +285,6 @@ create table @cdmDatabaseSchema.care_site (
 			location_id INT64,
 			care_site_source_value STRING,
 			place_of_service_source_value STRING );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.provider (
 			provider_id INT64 not null,
@@ -318,7 +300,6 @@ create table @cdmDatabaseSchema.provider (
 			specialty_source_concept_id INT64,
 			gender_source_value STRING,
 			gender_source_concept_id INT64 );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.payer_plan_period (
 			payer_plan_period_id INT64 not null,
@@ -338,7 +319,6 @@ create table @cdmDatabaseSchema.payer_plan_period (
 			stop_reason_concept_id INT64,
 			stop_reason_source_value STRING,
 			stop_reason_source_concept_id INT64 );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.cost (
 			cost_id INT64 not null,
@@ -346,24 +326,23 @@ create table @cdmDatabaseSchema.cost (
 			cost_domain_id STRING not null,
 			cost_type_concept_id INT64 not null,
 			currency_concept_id INT64,
-			total_charge FLOAT64 null,
-			total_cost FLOAT64 null,
-			total_paid FLOAT64 null,
-			paid_by_payer FLOAT64 null,
-			paid_by_patient FLOAT64 null,
-			paid_patient_copay FLOAT64 null,
-			paid_patient_coinsurance FLOAT64 null,
-			paid_patient_deductible FLOAT64 null,
-			paid_by_primary FLOAT64 null,
-			paid_ingredient_cost FLOAT64 null,
-			paid_dispensing_fee FLOAT64 null,
+			total_charge FLOAT64,
+			total_cost FLOAT64,
+			total_paid FLOAT64,
+			paid_by_payer FLOAT64,
+			paid_by_patient FLOAT64,
+			paid_patient_copay FLOAT64,
+			paid_patient_coinsurance FLOAT64,
+			paid_patient_deductible FLOAT64,
+			paid_by_primary FLOAT64,
+			paid_ingredient_cost FLOAT64,
+			paid_dispensing_fee FLOAT64,
 			payer_plan_period_id INT64,
-			amount_allowed FLOAT64 null,
+			amount_allowed FLOAT64,
 			revenue_code_concept_id INT64,
 			revenue_code_source_value STRING,
 			drg_concept_id INT64,
 			drg_source_value STRING );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.drug_era (
 			drug_era_id INT64 not null,
@@ -373,7 +352,6 @@ create table @cdmDatabaseSchema.drug_era (
 			drug_era_end_date date not null,
 			drug_exposure_count INT64,
 			gap_days INT64 );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.dose_era (
 			dose_era_id INT64 not null,
@@ -383,7 +361,6 @@ create table @cdmDatabaseSchema.dose_era (
 			dose_value FLOAT64 not null,
 			dose_era_start_date date not null,
 			dose_era_end_date date not null );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.condition_era (
 			condition_era_id INT64 not null,
@@ -392,29 +369,26 @@ create table @cdmDatabaseSchema.condition_era (
 			condition_era_start_date date not null,
 			condition_era_end_date date not null,
 			condition_occurrence_count INT64 );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 create table @cdmDatabaseSchema.episode (
 			episode_id INT64 not null,
 			person_id INT64 not null,
 			episode_concept_id INT64 not null,
 			episode_start_date date not null,
-			episode_start_datetime datetime null,
-			episode_end_date date null,
-			episode_end_datetime datetime null,
+			episode_start_datetime DATETIME,
+			episode_end_date DATE,
+			episode_end_datetime DATETIME,
 			episode_parent_id INT64,
 			episode_number INT64,
 			episode_object_concept_id INT64 not null,
 			episode_type_concept_id INT64 not null,
 			episode_source_value STRING,
 			episode_source_concept_id INT64 );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.episode_event (
 			episode_id INT64 not null,
 			event_id INT64 not null,
 			episode_event_field_concept_id INT64 not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.metadata (
 			metadata_id INT64 not null,
@@ -423,10 +397,9 @@ create table @cdmDatabaseSchema.metadata (
 			name STRING not null,
 			value_as_string STRING,
 			value_as_concept_id INT64,
-			value_as_number FLOAT64 null,
-			metadata_date date null,
-			metadata_datetime datetime null );
-
+			value_as_number FLOAT64,
+			metadata_date DATE,
+			metadata_datetime DATETIME );
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.cdm_source (
 			cdm_source_name STRING not null,
@@ -440,7 +413,6 @@ create table @cdmDatabaseSchema.cdm_source (
 			cdm_version STRING,
 			cdm_version_concept_id INT64 not null,
 			vocabulary_version STRING not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.concept (
 			concept_id INT64 not null,
@@ -453,7 +425,6 @@ create table @cdmDatabaseSchema.concept (
 			valid_start_date date not null,
 			valid_end_date date not null,
 			invalid_reason STRING );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.vocabulary (
 			vocabulary_id STRING not null,
@@ -461,19 +432,16 @@ create table @cdmDatabaseSchema.vocabulary (
 			vocabulary_reference STRING,
 			vocabulary_version STRING,
 			vocabulary_concept_id INT64 not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.domain (
 			domain_id STRING not null,
 			domain_name STRING not null,
 			domain_concept_id INT64 not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.concept_class (
 			concept_class_id STRING not null,
 			concept_class_name STRING not null,
 			concept_class_concept_id INT64 not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.concept_relationship (
 			concept_id_1 INT64 not null,
@@ -482,7 +450,6 @@ create table @cdmDatabaseSchema.concept_relationship (
 			valid_start_date date not null,
 			valid_end_date date not null,
 			invalid_reason STRING );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.relationship (
 			relationship_id STRING not null,
@@ -491,20 +458,17 @@ create table @cdmDatabaseSchema.relationship (
 			defines_ancestry STRING not null,
 			reverse_relationship_id STRING not null,
 			relationship_concept_id INT64 not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.concept_synonym (
 			concept_id INT64 not null,
 			concept_synonym_name STRING not null,
 			language_concept_id INT64 not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.concept_ancestor (
 			ancestor_concept_id INT64 not null,
 			descendant_concept_id INT64 not null,
 			min_levels_of_separation INT64 not null,
 			max_levels_of_separation INT64 not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.source_to_concept_map (
 			source_code STRING not null,
@@ -516,29 +480,26 @@ create table @cdmDatabaseSchema.source_to_concept_map (
 			valid_start_date date not null,
 			valid_end_date date not null,
 			invalid_reason STRING );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.drug_strength (
 			drug_concept_id INT64 not null,
 			ingredient_concept_id INT64 not null,
-			amount_value FLOAT64 null,
+			amount_value FLOAT64,
 			amount_unit_concept_id INT64,
-			numerator_value FLOAT64 null,
+			numerator_value FLOAT64,
 			numerator_unit_concept_id INT64,
-			denominator_value FLOAT64 null,
+			denominator_value FLOAT64,
 			denominator_unit_concept_id INT64,
 			box_size INT64,
 			valid_start_date date not null,
 			valid_end_date date not null,
 			invalid_reason STRING );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.cohort (
 			cohort_definition_id INT64 not null,
 			subject_id INT64 not null,
 			cohort_start_date date not null,
 			cohort_end_date date not null );
-
 --HINT DISTRIBUTE ON RANDOM
 create table @cdmDatabaseSchema.cohort_definition (
 			cohort_definition_id INT64 not null,
@@ -547,4 +508,4 @@ create table @cdmDatabaseSchema.cohort_definition (
 			definition_type_concept_id INT64 not null,
 			cohort_definition_syntax STRING,
 			subject_concept_id INT64 not null,
-			cohort_initiation_date date null );
\ No newline at end of file
+			cohort_initiation_date DATE );
\ No newline at end of file
diff --git a/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_indices.sql b/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_indices.sql
index 31213ac4..49b92706 100644
--- a/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_indices.sql
+++ b/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_indices.sql
@@ -1,158 +1,98 @@
 /*bigquery OMOP CDM Indices
-
   There are no unique indices created because it is assumed that the primary key constraints have been run prior to
   implementing indices.
 */
-
-
 /************************
-
 Standardized clinical data
-
 ************************/
-
 create clustered index idx_person_id on @cdmDatabaseSchema.person (person_id asc);
 -- bigquery does not support indexes
-
 create clustered index idx_observation_period_id_1 on @cdmDatabaseSchema.observation_period (person_id asc);
-
 create clustered index idx_visit_person_id_1 on @cdmDatabaseSchema.visit_occurrence (person_id asc);
 -- bigquery does not support indexes
-
 create clustered index idx_visit_det_person_id_1 on @cdmDatabaseSchema.visit_detail (person_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_condition_person_id_1 on @cdmDatabaseSchema.condition_occurrence (person_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_drug_person_id_1 on @cdmDatabaseSchema.drug_exposure (person_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_procedure_person_id_1 on @cdmDatabaseSchema.procedure_occurrence (person_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_device_person_id_1 on @cdmDatabaseSchema.device_exposure (person_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_measurement_person_id_1 on @cdmDatabaseSchema.measurement (person_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_observation_person_id_1 on @cdmDatabaseSchema.observation (person_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_death_person_id_1 on @cdmDatabaseSchema.death (person_id asc);
-
 create clustered index idx_note_person_id_1 on @cdmDatabaseSchema.note (person_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_note_nlp_note_id_1 on @cdmDatabaseSchema.note_nlp (note_id asc);
 -- bigquery does not support indexes
-
 create clustered index idx_specimen_person_id_1 on @cdmDatabaseSchema.specimen (person_id asc);
 -- bigquery does not support indexes
-
 -- bigquery does not support indexes
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 /************************
-
 Standardized health system data
-
 ************************/
-
 create clustered index idx_location_id_1 on @cdmDatabaseSchema.location (location_id asc);
-
 create clustered index idx_care_site_id_1 on @cdmDatabaseSchema.care_site (care_site_id asc);
-
 create clustered index idx_provider_id_1 on @cdmDatabaseSchema.provider (provider_id asc);
-
 /************************
-
 Standardized health economics
-
 ************************/
-
 create clustered index idx_period_person_id_1 on @cdmDatabaseSchema.payer_plan_period (person_id asc);
-
 -- bigquery does not support indexes
-
 /************************
-
 Standardized derived elements
-
 ************************/
-
 create clustered index idx_drug_era_person_id_1 on @cdmDatabaseSchema.drug_era (person_id asc);
 -- bigquery does not support indexes
-
 create clustered index idx_dose_era_person_id_1 on @cdmDatabaseSchema.dose_era (person_id asc);
 -- bigquery does not support indexes
-
 create clustered index idx_condition_era_person_id_1 on @cdmDatabaseSchema.condition_era (person_id asc);
 -- bigquery does not support indexes
-
 /**************************
-
 Standardized meta-data
-
 ***************************/
-
 create clustered index idx_metadata_concept_id_1 on @cdmDatabaseSchema.metadata (metadata_concept_id asc);
-
 /**************************
-
 Standardized vocabularies
-
 ***************************/
-
 create clustered index idx_concept_concept_id on @cdmDatabaseSchema.concept (concept_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_vocabulary_vocabulary_id on @cdmDatabaseSchema.vocabulary (vocabulary_id asc);
-
 create clustered index idx_domain_domain_id on @cdmDatabaseSchema.domain (domain_id asc);
-
 create clustered index idx_concept_class_class_id on @cdmDatabaseSchema.concept_class (concept_class_id asc);
-
 create clustered index idx_concept_relationship_id_1 on @cdmDatabaseSchema.concept_relationship (concept_id_1 asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_relationship_rel_id on @cdmDatabaseSchema.relationship (relationship_id asc);
-
 create clustered index idx_concept_synonym_id on @cdmDatabaseSchema.concept_synonym (concept_id asc);
-
 create clustered index idx_concept_ancestor_id_1 on @cdmDatabaseSchema.concept_ancestor (ancestor_concept_id asc);
 -- bigquery does not support indexes
-
 create clustered index idx_source_to_concept_map_3 on @cdmDatabaseSchema.source_to_concept_map (target_concept_id asc);
 -- bigquery does not support indexes
 -- bigquery does not support indexes
 -- bigquery does not support indexes
-
 create clustered index idx_drug_strength_id_1 on @cdmDatabaseSchema.drug_strength (drug_concept_id asc);
 -- bigquery does not support indexes
-
-
 --Additional v6.0 indices
-
 --CREATE CLUSTERED INDEX idx_survey_person_id_1 ON @cdmDatabaseSchema.survey_conduct (person_id ASC);
-
-
 --CREATE CLUSTERED INDEX idx_episode_person_id_1 ON @cdmDatabaseSchema.episode (person_id ASC);
 --CREATE INDEX idx_episode_concept_id_1 ON @cdmDatabaseSchema.episode (episode_concept_id ASC);
-
 --CREATE CLUSTERED INDEX idx_episode_event_id_1 ON @cdmDatabaseSchema.episode_event (episode_id ASC);
 --CREATE INDEX idx_ee_field_concept_id_1 ON @cdmDatabaseSchema.episode_event (event_field_concept_id ASC);
diff --git a/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_primary_keys.sql b/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_primary_keys.sql
index 0f3ae5a6..a4a67ec2 100644
--- a/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_primary_keys.sql
+++ b/inst/ddl/5.4/bigquery/OMOPCDM_bigquery_5.4_primary_keys.sql
@@ -1,57 +1,29 @@
 --bigquery CDM Primary Key Constraints for OMOP Common Data Model 5.4
-
 alter table @cdmDatabaseSchema.person add constraint xpk_person primary key nonclustered (person_id);
-
 alter table @cdmDatabaseSchema.observation_period add constraint xpk_observation_period primary key nonclustered (observation_period_id);
-
 alter table @cdmDatabaseSchema.visit_occurrence add constraint xpk_visit_occurrence primary key nonclustered (visit_occurrence_id);
-
 alter table @cdmDatabaseSchema.visit_detail add constraint xpk_visit_detail primary key nonclustered (visit_detail_id);
-
 alter table @cdmDatabaseSchema.condition_occurrence add constraint xpk_condition_occurrence primary key nonclustered (condition_occurrence_id);
-
 alter table @cdmDatabaseSchema.drug_exposure add constraint xpk_drug_exposure primary key nonclustered (drug_exposure_id);
-
 alter table @cdmDatabaseSchema.procedure_occurrence add constraint xpk_procedure_occurrence primary key nonclustered (procedure_occurrence_id);
-
 alter table @cdmDatabaseSchema.device_exposure add constraint xpk_device_exposure primary key nonclustered (device_exposure_id);
-
 alter table @cdmDatabaseSchema.measurement add constraint xpk_measurement primary key nonclustered (measurement_id);
-
 alter table @cdmDatabaseSchema.observation add constraint xpk_observation primary key nonclustered (observation_id);
-
 alter table @cdmDatabaseSchema.note add constraint xpk_note primary key nonclustered (note_id);
-
 alter table @cdmDatabaseSchema.note_nlp add constraint xpk_note_nlp primary key nonclustered (note_nlp_id);
-
 alter table @cdmDatabaseSchema.specimen add constraint xpk_specimen primary key nonclustered (specimen_id);
-
 alter table @cdmDatabaseSchema.location add constraint xpk_location primary key nonclustered (location_id);
-
 alter table @cdmDatabaseSchema.care_site add constraint xpk_care_site primary key nonclustered (care_site_id);
-
 alter table @cdmDatabaseSchema.provider add constraint xpk_provider primary key nonclustered (provider_id);
-
 alter table @cdmDatabaseSchema.payer_plan_period add constraint xpk_payer_plan_period primary key nonclustered (payer_plan_period_id);
-
 alter table @cdmDatabaseSchema.cost add constraint xpk_cost primary key nonclustered (cost_id);
-
 alter table @cdmDatabaseSchema.drug_era add constraint xpk_drug_era primary key nonclustered (drug_era_id);
-
 alter table @cdmDatabaseSchema.dose_era add constraint xpk_dose_era primary key nonclustered (dose_era_id);
-
 alter table @cdmDatabaseSchema.condition_era add constraint xpk_condition_era primary key nonclustered (condition_era_id);
-
 alter table @cdmDatabaseSchema.episode add constraint xpk_episode primary key nonclustered (episode_id);
-
 alter table @cdmDatabaseSchema.metadata add constraint xpk_metadata primary key nonclustered (metadata_id);
-
 alter table @cdmDatabaseSchema.concept add constraint xpk_concept primary key nonclustered (concept_id);
-
 alter table @cdmDatabaseSchema.vocabulary add constraint xpk_vocabulary primary key nonclustered (vocabulary_id);
-
 alter table @cdmDatabaseSchema.domain add constraint xpk_domain primary key nonclustered (domain_id);
-
 alter table @cdmDatabaseSchema.concept_class add constraint xpk_concept_class primary key nonclustered (concept_class_id);
-
 alter table @cdmDatabaseSchema.relationship add constraint xpk_relationship primary key nonclustered (relationship_id);
diff --git a/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_constraints.sql b/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_constraints.sql
index aa0ea25e..a9b21f82 100644
--- a/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_constraints.sql
+++ b/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_constraints.sql
@@ -1,353 +1,177 @@
 --impala CDM Foreign Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_concept_id FOREIGN KEY (race_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_concept_id FOREIGN KEY (ethnicity_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.`location` (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_source_concept_id FOREIGN KEY (race_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_source_concept_id FOREIGN KEY (ethnicity_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_period_type_concept_id FOREIGN KEY (period_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_concept_id FOREIGN KEY (visit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_type_concept_id FOREIGN KEY (visit_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_source_concept_id FOREIGN KEY (visit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_preceding_visit_occurrence_id FOREIGN KEY (preceding_visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_concept_id FOREIGN KEY (visit_detail_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_type_concept_id FOREIGN KEY (visit_detail_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_source_concept_id FOREIGN KEY (visit_detail_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_preceding_visit_detail_id FOREIGN KEY (preceding_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_parent_visit_detail_id FOREIGN KEY (parent_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_type_concept_id FOREIGN KEY (condition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_status_concept_id FOREIGN KEY (condition_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_source_concept_id FOREIGN KEY (condition_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_type_concept_id FOREIGN KEY (drug_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_route_concept_id FOREIGN KEY (route_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_source_concept_id FOREIGN KEY (drug_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_concept_id FOREIGN KEY (procedure_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_type_concept_id FOREIGN KEY (procedure_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_modifier_concept_id FOREIGN KEY (modifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_source_concept_id FOREIGN KEY (procedure_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_concept_id FOREIGN KEY (device_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_type_concept_id FOREIGN KEY (device_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_source_concept_id FOREIGN KEY (device_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_concept_id FOREIGN KEY (measurement_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_type_concept_id FOREIGN KEY (measurement_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_operator_concept_id FOREIGN KEY (operator_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_source_concept_id FOREIGN KEY (measurement_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_meas_event_field_concept_id FOREIGN KEY (meas_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_concept_id FOREIGN KEY (observation_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_type_concept_id FOREIGN KEY (observation_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_qualifier_concept_id FOREIGN KEY (qualifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_source_concept_id FOREIGN KEY (observation_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_obs_event_field_concept_id FOREIGN KEY (obs_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_death_type_concept_id FOREIGN KEY (death_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_concept_id FOREIGN KEY (cause_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_source_concept_id FOREIGN KEY (cause_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_type_concept_id FOREIGN KEY (note_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_class_concept_id FOREIGN KEY (note_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_encoding_concept_id FOREIGN KEY (encoding_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_event_field_concept_id FOREIGN KEY (note_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_section_concept_id FOREIGN KEY (section_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_concept_id FOREIGN KEY (note_nlp_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_source_concept_id FOREIGN KEY (note_nlp_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_concept_id FOREIGN KEY (specimen_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_type_concept_id FOREIGN KEY (specimen_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_anatomic_site_concept_id FOREIGN KEY (anatomic_site_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_disease_status_concept_id FOREIGN KEY (disease_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_1 FOREIGN KEY (domain_concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_2 FOREIGN KEY (domain_concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.`location` ADD CONSTRAINT fpk_LOCATION_country_concept_id FOREIGN KEY (country_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_place_of_service_concept_id FOREIGN KEY (place_of_service_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.`location` (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_concept_id FOREIGN KEY (specialty_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_source_concept_id FOREIGN KEY (specialty_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_concept_id FOREIGN KEY (payer_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_source_concept_id FOREIGN KEY (payer_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_concept_id FOREIGN KEY (plan_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_source_concept_id FOREIGN KEY (plan_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_concept_id FOREIGN KEY (sponsor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_source_concept_id FOREIGN KEY (sponsor_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_concept_id FOREIGN KEY (stop_reason_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_source_concept_id FOREIGN KEY (stop_reason_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_domain_id FOREIGN KEY (cost_domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_type_concept_id FOREIGN KEY (cost_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_currency_concept_id FOREIGN KEY (currency_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_revenue_code_concept_id FOREIGN KEY (revenue_code_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_drg_concept_id FOREIGN KEY (drg_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_concept_id FOREIGN KEY (episode_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_object_concept_id FOREIGN KEY (episode_object_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_type_concept_id FOREIGN KEY (episode_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_source_concept_id FOREIGN KEY (episode_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_id FOREIGN KEY (episode_id) REFERENCES @cdmDatabaseSchema.EPISODE (EPISODE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_event_field_concept_id FOREIGN KEY (episode_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_concept_id FOREIGN KEY (metadata_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_type_concept_id FOREIGN KEY (metadata_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CDM_SOURCE ADD CONSTRAINT fpk_CDM_SOURCE_cdm_version_concept_id FOREIGN KEY (cdm_version_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_domain_id FOREIGN KEY (domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_vocabulary_id FOREIGN KEY (vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_concept_class_id FOREIGN KEY (concept_class_id) REFERENCES @cdmDatabaseSchema.CONCEPT_CLASS (CONCEPT_CLASS_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT fpk_VOCABULARY_vocabulary_concept_id FOREIGN KEY (vocabulary_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT fpk_DOMAIN_domain_concept_id FOREIGN KEY (domain_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT fpk_CONCEPT_CLASS_concept_class_concept_id FOREIGN KEY (concept_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_1 FOREIGN KEY (concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_2 FOREIGN KEY (concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_relationship_id FOREIGN KEY (relationship_id) REFERENCES @cdmDatabaseSchema.RELATIONSHIP (RELATIONSHIP_ID);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT fpk_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_concept_id FOREIGN KEY (concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_ancestor_concept_id FOREIGN KEY (ancestor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_descendant_concept_id FOREIGN KEY (descendant_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_source_concept_id FOREIGN KEY (source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_concept_id FOREIGN KEY (target_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_vocabulary_id FOREIGN KEY (target_vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_ingredient_concept_id FOREIGN KEY (ingredient_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_amount_unit_concept_id FOREIGN KEY (amount_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_numerator_unit_concept_id FOREIGN KEY (numerator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_denominator_unit_concept_id FOREIGN KEY (denominator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_definition_type_concept_id FOREIGN KEY (definition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_subject_concept_id FOREIGN KEY (subject_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
diff --git a/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_ddl.sql b/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_ddl.sql
index 9ad65d27..d24bbaae 100644
--- a/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_ddl.sql
+++ b/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_ddl.sql
@@ -1,5 +1,4 @@
 --impala CDM DDL Specification for OMOP Common Data Model 5.4
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PERSON (
 			person_id INT,
@@ -20,7 +19,6 @@ CREATE TABLE @cdmDatabaseSchema.PERSON (
 			race_source_concept_id integer NULL,
 			ethnicity_source_value VARCHAR(50),
 			ethnicity_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
 			observation_period_id INT,
@@ -28,7 +26,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
 			observation_period_start_date TIMESTAMP,
 			observation_period_end_date TIMESTAMP,
 			period_type_concept_id INT );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
 			visit_occurrence_id INT,
@@ -48,7 +45,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
 			discharged_to_concept_id integer NULL,
 			discharged_to_source_value VARCHAR(50),
 			preceding_visit_occurrence_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
 			visit_detail_id INT,
@@ -70,7 +66,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
 			preceding_visit_detail_id integer NULL,
 			parent_visit_detail_id integer NULL,
 			visit_occurrence_id INT );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
 			condition_occurrence_id INT,
@@ -89,7 +84,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
 			condition_source_value VARCHAR(50),
 			condition_source_concept_id integer NULL,
 			condition_status_source_value VARCHAR(50) );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
 			drug_exposure_id INT,
@@ -115,7 +109,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
 			drug_source_concept_id integer NULL,
 			route_source_value VARCHAR(50),
 			dose_unit_source_value VARCHAR(50) );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
 			procedure_occurrence_id INT,
@@ -134,7 +127,6 @@ CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
 			procedure_source_value VARCHAR(50),
 			procedure_source_concept_id integer NULL,
 			modifier_source_value VARCHAR(50) );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
 			device_exposure_id INT,
@@ -156,7 +148,6 @@ CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
 			unit_concept_id integer NULL,
 			unit_source_value VARCHAR(50),
 			unit_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
 			measurement_id INT,
@@ -182,7 +173,6 @@ CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
 			value_source_value VARCHAR(50),
 			measurement_event_id integer NULL,
 			meas_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
 			observation_id INT,
@@ -206,7 +196,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
 			value_source_value VARCHAR(50),
 			observation_event_id integer NULL,
 			obs_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEATH (
 			person_id INT,
@@ -216,7 +205,6 @@ CREATE TABLE @cdmDatabaseSchema.DEATH (
 			cause_concept_id integer NULL,
 			cause_source_value VARCHAR(50),
 			cause_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.NOTE (
 			note_id INT,
@@ -235,7 +223,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE (
 			note_source_value VARCHAR(50),
 			note_event_id integer NULL,
 			note_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
 			note_nlp_id INT,
@@ -252,7 +239,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
 			term_exists VARCHAR(1),
 			term_temporal VARCHAR(50),
 			term_modifiers VARCHAR(2000) );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
 			specimen_id INT,
@@ -270,7 +256,6 @@ CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
 			unit_source_value VARCHAR(50),
 			anatomic_site_source_value VARCHAR(50),
 			disease_status_source_value VARCHAR(50) );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
 			domain_concept_id_1 INT,
@@ -278,7 +263,6 @@ CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
 			domain_concept_id_2 INT,
 			fact_id_2 INT,
 			relationship_concept_id INT );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.`location` (
 			location_id INT,
@@ -293,7 +277,6 @@ CREATE TABLE @cdmDatabaseSchema.`location` (
 			country_source_value VARCHAR(80),
 			latitude FLOAT,
 			longitude FLOAT );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
 			care_site_id INT,
@@ -302,7 +285,6 @@ CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
 			location_id integer NULL,
 			care_site_source_value VARCHAR(50),
 			place_of_service_source_value VARCHAR(50) );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.PROVIDER (
 			provider_id INT,
@@ -318,7 +300,6 @@ CREATE TABLE @cdmDatabaseSchema.PROVIDER (
 			specialty_source_concept_id integer NULL,
 			gender_source_value VARCHAR(50),
 			gender_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
 			payer_plan_period_id INT,
@@ -338,7 +319,6 @@ CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
 			stop_reason_concept_id integer NULL,
 			stop_reason_source_value VARCHAR(50),
 			stop_reason_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COST (
 			cost_id INT,
@@ -363,7 +343,6 @@ CREATE TABLE @cdmDatabaseSchema.COST (
 			revenue_code_source_value VARCHAR(50),
 			drg_concept_id integer NULL,
 			drg_source_value VARCHAR(3) );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
 			drug_era_id INT,
@@ -373,7 +352,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
 			drug_era_end_date TIMESTAMP,
 			drug_exposure_count integer NULL,
 			gap_days integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
 			dose_era_id INT,
@@ -383,7 +361,6 @@ CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
 			dose_value FLOAT,
 			dose_era_start_date TIMESTAMP,
 			dose_era_end_date TIMESTAMP );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
 			condition_era_id INT,
@@ -392,7 +369,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
 			condition_era_start_date TIMESTAMP,
 			condition_era_end_date TIMESTAMP,
 			condition_occurrence_count integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.EPISODE (
 			episode_id INT,
@@ -408,13 +384,11 @@ CREATE TABLE @cdmDatabaseSchema.EPISODE (
 			episode_type_concept_id INT,
 			episode_source_value VARCHAR(50),
 			episode_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT (
 			episode_id INT,
 			event_id INT,
 			episode_event_field_concept_id INT );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.METADATA (
 			metadata_id INT,
@@ -426,7 +400,6 @@ CREATE TABLE @cdmDatabaseSchema.METADATA (
 			value_as_number FLOAT,
 			metadata_date TIMESTAMP,
 			metadata_datetime TIMESTAMP );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
 			cdm_source_name VARCHAR(255),
@@ -440,7 +413,6 @@ CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
 			cdm_version VARCHAR(10),
 			cdm_version_concept_id INT,
 			vocabulary_version VARCHAR(20) );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT (
 			concept_id INT,
@@ -453,7 +425,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT (
 			valid_start_date TIMESTAMP,
 			valid_end_date TIMESTAMP,
 			invalid_reason VARCHAR(1) );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
 			vocabulary_id VARCHAR(20),
@@ -461,19 +432,16 @@ CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
 			vocabulary_reference VARCHAR(255),
 			vocabulary_version VARCHAR(255),
 			vocabulary_concept_id INT );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DOMAIN (
 			domain_id VARCHAR(20),
 			domain_name VARCHAR(255),
 			domain_concept_id INT );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS (
 			concept_class_id VARCHAR(20),
 			concept_class_name VARCHAR(255),
 			concept_class_concept_id INT );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
 			concept_id_1 INT,
@@ -482,7 +450,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
 			valid_start_date TIMESTAMP,
 			valid_end_date TIMESTAMP,
 			invalid_reason VARCHAR(1) );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
 			relationship_id VARCHAR(20),
@@ -491,20 +458,17 @@ CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
 			defines_ancestry VARCHAR(1),
 			reverse_relationship_id VARCHAR(20),
 			relationship_concept_id INT );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM (
 			concept_id INT,
 			concept_synonym_name VARCHAR(1000),
 			language_concept_id INT );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR (
 			ancestor_concept_id INT,
 			descendant_concept_id INT,
 			min_levels_of_separation INT,
 			max_levels_of_separation INT );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
 			source_code VARCHAR(50),
@@ -516,7 +480,6 @@ CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
 			valid_start_date TIMESTAMP,
 			valid_end_date TIMESTAMP,
 			invalid_reason VARCHAR(1) );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
 			drug_concept_id INT,
@@ -531,14 +494,12 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
 			valid_start_date TIMESTAMP,
 			valid_end_date TIMESTAMP,
 			invalid_reason VARCHAR(1) );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT (
 			cohort_definition_id INT,
 			subject_id INT,
 			cohort_start_date TIMESTAMP,
 			cohort_end_date TIMESTAMP );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION (
 			cohort_definition_id INT,
diff --git a/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_indices.sql b/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_indices.sql
index d6b15c44..07ba45f5 100644
--- a/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_indices.sql
+++ b/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_indices.sql
@@ -1,158 +1,98 @@
 /*impala OMOP CDM Indices
-
   There are no unique indices created because it is assumed that the primary key constraints have been run prior to
   implementing indices.
 */
-
-
 /************************
-
 Standardized clinical data
-
 ************************/
-
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 /************************
-
 Standardized health system data
-
 ************************/
-
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 /************************
-
 Standardized health economics
-
 ************************/
-
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 /************************
-
 Standardized derived elements
-
 ************************/
-
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
-
 /**************************
-
 Standardized meta-data
-
 ***************************/
-
 -- impala does not support indexes
-
 /**************************
-
 Standardized vocabularies
-
 ***************************/
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
 -- impala does not support indexes
-
 -- impala does not support indexes
 -- impala does not support indexes
-
-
 --Additional v6.0 indices
-
 --CREATE CLUSTERED INDEX idx_survey_person_id_1 ON @cdmDatabaseSchema.survey_conduct (person_id ASC);
-
-
 --CREATE CLUSTERED INDEX idx_episode_person_id_1 ON @cdmDatabaseSchema.episode (person_id ASC);
 --CREATE INDEX idx_episode_concept_id_1 ON @cdmDatabaseSchema.episode (episode_concept_id ASC);
-
 --CREATE CLUSTERED INDEX idx_episode_event_id_1 ON @cdmDatabaseSchema.episode_event (episode_id ASC);
 --CREATE INDEX idx_ee_field_concept_id_1 ON @cdmDatabaseSchema.episode_event (event_field_concept_id ASC);
diff --git a/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_primary_keys.sql b/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_primary_keys.sql
index df481e93..f5e4bf63 100644
--- a/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_primary_keys.sql
+++ b/inst/ddl/5.4/impala/OMOPCDM_impala_5.4_primary_keys.sql
@@ -1,57 +1,29 @@
 --impala CDM Primary Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT xpk_PERSON PRIMARY KEY NONCLUSTERED (person_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT xpk_OBSERVATION_PERIOD PRIMARY KEY NONCLUSTERED (observation_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT xpk_VISIT_OCCURRENCE PRIMARY KEY NONCLUSTERED (visit_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT xpk_VISIT_DETAIL PRIMARY KEY NONCLUSTERED (visit_detail_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT xpk_CONDITION_OCCURRENCE PRIMARY KEY NONCLUSTERED (condition_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT xpk_DRUG_EXPOSURE PRIMARY KEY NONCLUSTERED (drug_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT xpk_PROCEDURE_OCCURRENCE PRIMARY KEY NONCLUSTERED (procedure_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT xpk_DEVICE_EXPOSURE PRIMARY KEY NONCLUSTERED (device_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT xpk_MEASUREMENT PRIMARY KEY NONCLUSTERED (measurement_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT xpk_OBSERVATION PRIMARY KEY NONCLUSTERED (observation_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT xpk_NOTE PRIMARY KEY NONCLUSTERED (note_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT xpk_NOTE_NLP PRIMARY KEY NONCLUSTERED (note_nlp_id);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT xpk_SPECIMEN PRIMARY KEY NONCLUSTERED (specimen_id);
-
 ALTER TABLE @cdmDatabaseSchema.`location` ADD CONSTRAINT xpk_LOCATION PRIMARY KEY NONCLUSTERED (location_id);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT xpk_CARE_SITE PRIMARY KEY NONCLUSTERED (care_site_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT xpk_PROVIDER PRIMARY KEY NONCLUSTERED (provider_id);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT xpk_PAYER_PLAN_PERIOD PRIMARY KEY NONCLUSTERED (payer_plan_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT xpk_COST PRIMARY KEY NONCLUSTERED (cost_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT xpk_DRUG_ERA PRIMARY KEY NONCLUSTERED (drug_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT xpk_DOSE_ERA PRIMARY KEY NONCLUSTERED (dose_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT xpk_CONDITION_ERA PRIMARY KEY NONCLUSTERED (condition_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT xpk_EPISODE PRIMARY KEY NONCLUSTERED (episode_id);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT xpk_METADATA PRIMARY KEY NONCLUSTERED (metadata_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT xpk_CONCEPT PRIMARY KEY NONCLUSTERED (concept_id);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT xpk_VOCABULARY PRIMARY KEY NONCLUSTERED (vocabulary_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT xpk_DOMAIN PRIMARY KEY NONCLUSTERED (domain_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT xpk_CONCEPT_CLASS PRIMARY KEY NONCLUSTERED (concept_class_id);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY NONCLUSTERED (relationship_id);
diff --git a/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_constraints.sql b/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_constraints.sql
index dd4ec546..fd16facf 100644
--- a/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_constraints.sql
+++ b/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_constraints.sql
@@ -1,353 +1,177 @@
 --netezza CDM Foreign Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_concept_id FOREIGN KEY (race_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_concept_id FOREIGN KEY (ethnicity_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_source_concept_id FOREIGN KEY (race_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_source_concept_id FOREIGN KEY (ethnicity_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_period_type_concept_id FOREIGN KEY (period_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_concept_id FOREIGN KEY (visit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_type_concept_id FOREIGN KEY (visit_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_source_concept_id FOREIGN KEY (visit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_preceding_visit_occurrence_id FOREIGN KEY (preceding_visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_concept_id FOREIGN KEY (visit_detail_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_type_concept_id FOREIGN KEY (visit_detail_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_source_concept_id FOREIGN KEY (visit_detail_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_preceding_visit_detail_id FOREIGN KEY (preceding_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_parent_visit_detail_id FOREIGN KEY (parent_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_type_concept_id FOREIGN KEY (condition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_status_concept_id FOREIGN KEY (condition_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_source_concept_id FOREIGN KEY (condition_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_type_concept_id FOREIGN KEY (drug_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_route_concept_id FOREIGN KEY (route_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_source_concept_id FOREIGN KEY (drug_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_concept_id FOREIGN KEY (procedure_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_type_concept_id FOREIGN KEY (procedure_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_modifier_concept_id FOREIGN KEY (modifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_source_concept_id FOREIGN KEY (procedure_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_concept_id FOREIGN KEY (device_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_type_concept_id FOREIGN KEY (device_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_source_concept_id FOREIGN KEY (device_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_concept_id FOREIGN KEY (measurement_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_type_concept_id FOREIGN KEY (measurement_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_operator_concept_id FOREIGN KEY (operator_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_source_concept_id FOREIGN KEY (measurement_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_meas_event_field_concept_id FOREIGN KEY (meas_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_concept_id FOREIGN KEY (observation_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_type_concept_id FOREIGN KEY (observation_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_qualifier_concept_id FOREIGN KEY (qualifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_source_concept_id FOREIGN KEY (observation_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_obs_event_field_concept_id FOREIGN KEY (obs_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_death_type_concept_id FOREIGN KEY (death_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_concept_id FOREIGN KEY (cause_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_source_concept_id FOREIGN KEY (cause_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_type_concept_id FOREIGN KEY (note_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_class_concept_id FOREIGN KEY (note_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_encoding_concept_id FOREIGN KEY (encoding_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_event_field_concept_id FOREIGN KEY (note_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_section_concept_id FOREIGN KEY (section_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_concept_id FOREIGN KEY (note_nlp_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_source_concept_id FOREIGN KEY (note_nlp_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_concept_id FOREIGN KEY (specimen_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_type_concept_id FOREIGN KEY (specimen_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_anatomic_site_concept_id FOREIGN KEY (anatomic_site_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_disease_status_concept_id FOREIGN KEY (disease_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_1 FOREIGN KEY (domain_concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_2 FOREIGN KEY (domain_concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT fpk_LOCATION_country_concept_id FOREIGN KEY (country_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_place_of_service_concept_id FOREIGN KEY (place_of_service_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_concept_id FOREIGN KEY (specialty_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_source_concept_id FOREIGN KEY (specialty_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_concept_id FOREIGN KEY (payer_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_source_concept_id FOREIGN KEY (payer_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_concept_id FOREIGN KEY (plan_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_source_concept_id FOREIGN KEY (plan_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_concept_id FOREIGN KEY (sponsor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_source_concept_id FOREIGN KEY (sponsor_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_concept_id FOREIGN KEY (stop_reason_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_source_concept_id FOREIGN KEY (stop_reason_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_domain_id FOREIGN KEY (cost_domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_type_concept_id FOREIGN KEY (cost_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_currency_concept_id FOREIGN KEY (currency_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_revenue_code_concept_id FOREIGN KEY (revenue_code_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_drg_concept_id FOREIGN KEY (drg_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_concept_id FOREIGN KEY (episode_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_object_concept_id FOREIGN KEY (episode_object_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_type_concept_id FOREIGN KEY (episode_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_source_concept_id FOREIGN KEY (episode_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_id FOREIGN KEY (episode_id) REFERENCES @cdmDatabaseSchema.EPISODE (EPISODE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_event_field_concept_id FOREIGN KEY (episode_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_concept_id FOREIGN KEY (metadata_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_type_concept_id FOREIGN KEY (metadata_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CDM_SOURCE ADD CONSTRAINT fpk_CDM_SOURCE_cdm_version_concept_id FOREIGN KEY (cdm_version_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_domain_id FOREIGN KEY (domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_vocabulary_id FOREIGN KEY (vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_concept_class_id FOREIGN KEY (concept_class_id) REFERENCES @cdmDatabaseSchema.CONCEPT_CLASS (CONCEPT_CLASS_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT fpk_VOCABULARY_vocabulary_concept_id FOREIGN KEY (vocabulary_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT fpk_DOMAIN_domain_concept_id FOREIGN KEY (domain_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT fpk_CONCEPT_CLASS_concept_class_concept_id FOREIGN KEY (concept_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_1 FOREIGN KEY (concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_2 FOREIGN KEY (concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_relationship_id FOREIGN KEY (relationship_id) REFERENCES @cdmDatabaseSchema.RELATIONSHIP (RELATIONSHIP_ID);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT fpk_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_concept_id FOREIGN KEY (concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_ancestor_concept_id FOREIGN KEY (ancestor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_descendant_concept_id FOREIGN KEY (descendant_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_source_concept_id FOREIGN KEY (source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_concept_id FOREIGN KEY (target_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_vocabulary_id FOREIGN KEY (target_vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_ingredient_concept_id FOREIGN KEY (ingredient_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_amount_unit_concept_id FOREIGN KEY (amount_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_numerator_unit_concept_id FOREIGN KEY (numerator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_denominator_unit_concept_id FOREIGN KEY (denominator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_definition_type_concept_id FOREIGN KEY (definition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_subject_concept_id FOREIGN KEY (subject_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
diff --git a/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_ddl.sql b/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_ddl.sql
index ee62ec5a..1ab7961e 100644
--- a/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_ddl.sql
+++ b/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_ddl.sql
@@ -1,5 +1,4 @@
 --netezza CDM DDL Specification for OMOP Common Data Model 5.4
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PERSON (
 			person_id integer NOT NULL,
@@ -20,7 +19,6 @@ CREATE TABLE @cdmDatabaseSchema.PERSON (
 			race_source_concept_id integer NULL,
 			ethnicity_source_value varchar(50) NULL,
 			ethnicity_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
 			observation_period_id integer NOT NULL,
@@ -28,7 +26,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
 			observation_period_start_date date NOT NULL,
 			observation_period_end_date date NOT NULL,
 			period_type_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
 			visit_occurrence_id integer NOT NULL,
@@ -48,7 +45,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
 			discharged_to_concept_id integer NULL,
 			discharged_to_source_value varchar(50) NULL,
 			preceding_visit_occurrence_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
 			visit_detail_id integer NOT NULL,
@@ -70,7 +66,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
 			preceding_visit_detail_id integer NULL,
 			parent_visit_detail_id integer NULL,
 			visit_occurrence_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
 			condition_occurrence_id integer NOT NULL,
@@ -89,7 +84,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
 			condition_source_value varchar(50) NULL,
 			condition_source_concept_id integer NULL,
 			condition_status_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
 			drug_exposure_id integer NOT NULL,
@@ -115,7 +109,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
 			drug_source_concept_id integer NULL,
 			route_source_value varchar(50) NULL,
 			dose_unit_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
 			procedure_occurrence_id integer NOT NULL,
@@ -134,7 +127,6 @@ CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
 			procedure_source_value varchar(50) NULL,
 			procedure_source_concept_id integer NULL,
 			modifier_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
 			device_exposure_id integer NOT NULL,
@@ -156,7 +148,6 @@ CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
 			unit_concept_id integer NULL,
 			unit_source_value varchar(50) NULL,
 			unit_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
 			measurement_id integer NOT NULL,
@@ -182,7 +173,6 @@ CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
 			value_source_value varchar(50) NULL,
 			measurement_event_id integer NULL,
 			meas_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
 			observation_id integer NOT NULL,
@@ -206,7 +196,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
 			value_source_value varchar(50) NULL,
 			observation_event_id integer NULL,
 			obs_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEATH (
 			person_id integer NOT NULL,
@@ -216,7 +205,6 @@ CREATE TABLE @cdmDatabaseSchema.DEATH (
 			cause_concept_id integer NULL,
 			cause_source_value varchar(50) NULL,
 			cause_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.NOTE (
 			note_id integer NOT NULL,
@@ -235,7 +223,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE (
 			note_source_value varchar(50) NULL,
 			note_event_id integer NULL,
 			note_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
 			note_nlp_id integer NOT NULL,
@@ -252,7 +239,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
 			term_exists varchar(1) NULL,
 			term_temporal varchar(50) NULL,
 			term_modifiers varchar(2000) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
 			specimen_id integer NOT NULL,
@@ -270,7 +256,6 @@ CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
 			unit_source_value varchar(50) NULL,
 			anatomic_site_source_value varchar(50) NULL,
 			disease_status_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
 			domain_concept_id_1 integer NOT NULL,
@@ -278,7 +263,6 @@ CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
 			domain_concept_id_2 integer NOT NULL,
 			fact_id_2 integer NOT NULL,
 			relationship_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.LOCATION (
 			location_id integer NOT NULL,
@@ -293,7 +277,6 @@ CREATE TABLE @cdmDatabaseSchema.LOCATION (
 			country_source_value varchar(80) NULL,
 			latitude FLOAT(6) NULL,
 			longitude FLOAT(6) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
 			care_site_id integer NOT NULL,
@@ -302,7 +285,6 @@ CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
 			location_id integer NULL,
 			care_site_source_value varchar(50) NULL,
 			place_of_service_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.PROVIDER (
 			provider_id integer NOT NULL,
@@ -318,7 +300,6 @@ CREATE TABLE @cdmDatabaseSchema.PROVIDER (
 			specialty_source_concept_id integer NULL,
 			gender_source_value varchar(50) NULL,
 			gender_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
 			payer_plan_period_id integer NOT NULL,
@@ -338,7 +319,6 @@ CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
 			stop_reason_concept_id integer NULL,
 			stop_reason_source_value varchar(50) NULL,
 			stop_reason_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COST (
 			cost_id integer NOT NULL,
@@ -363,7 +343,6 @@ CREATE TABLE @cdmDatabaseSchema.COST (
 			revenue_code_source_value varchar(50) NULL,
 			drg_concept_id integer NULL,
 			drg_source_value varchar(3) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
 			drug_era_id integer NOT NULL,
@@ -373,7 +352,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
 			drug_era_end_date date NOT NULL,
 			drug_exposure_count integer NULL,
 			gap_days integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
 			dose_era_id integer NOT NULL,
@@ -383,7 +361,6 @@ CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
 			dose_value FLOAT(6) NOT NULL,
 			dose_era_start_date date NOT NULL,
 			dose_era_end_date date NOT NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
 			condition_era_id integer NOT NULL,
@@ -392,7 +369,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
 			condition_era_start_date date NOT NULL,
 			condition_era_end_date date NOT NULL,
 			condition_occurrence_count integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.EPISODE (
 			episode_id integer NOT NULL,
@@ -408,13 +384,11 @@ CREATE TABLE @cdmDatabaseSchema.EPISODE (
 			episode_type_concept_id integer NOT NULL,
 			episode_source_value varchar(50) NULL,
 			episode_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT (
 			episode_id integer NOT NULL,
 			event_id integer NOT NULL,
 			episode_event_field_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.METADATA (
 			metadata_id integer NOT NULL,
@@ -426,7 +400,6 @@ CREATE TABLE @cdmDatabaseSchema.METADATA (
 			value_as_number FLOAT(6) NULL,
 			metadata_date date NULL,
 			metadata_datetime TIMESTAMP NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
 			cdm_source_name varchar(255) NOT NULL,
@@ -440,7 +413,6 @@ CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
 			cdm_version varchar(10) NULL,
 			cdm_version_concept_id integer NOT NULL,
 			vocabulary_version varchar(20) NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT (
 			concept_id integer NOT NULL,
@@ -453,7 +425,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
 			vocabulary_id varchar(20) NOT NULL,
@@ -461,19 +432,16 @@ CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
 			vocabulary_reference varchar(255) NULL,
 			vocabulary_version varchar(255) NULL,
 			vocabulary_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DOMAIN (
 			domain_id varchar(20) NOT NULL,
 			domain_name varchar(255) NOT NULL,
 			domain_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS (
 			concept_class_id varchar(20) NOT NULL,
 			concept_class_name varchar(255) NOT NULL,
 			concept_class_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
 			concept_id_1 integer NOT NULL,
@@ -482,7 +450,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
 			relationship_id varchar(20) NOT NULL,
@@ -491,20 +458,17 @@ CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
 			defines_ancestry varchar(1) NOT NULL,
 			reverse_relationship_id varchar(20) NOT NULL,
 			relationship_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM (
 			concept_id integer NOT NULL,
 			concept_synonym_name varchar(1000) NOT NULL,
 			language_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR (
 			ancestor_concept_id integer NOT NULL,
 			descendant_concept_id integer NOT NULL,
 			min_levels_of_separation integer NOT NULL,
 			max_levels_of_separation integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
 			source_code varchar(50) NOT NULL,
@@ -516,7 +480,6 @@ CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
 			drug_concept_id integer NOT NULL,
@@ -531,14 +494,12 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT (
 			cohort_definition_id integer NOT NULL,
 			subject_id integer NOT NULL,
 			cohort_start_date date NOT NULL,
 			cohort_end_date date NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION (
 			cohort_definition_id integer NOT NULL,
diff --git a/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_indices.sql b/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_indices.sql
index 1e671b54..f9d5919f 100644
--- a/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_indices.sql
+++ b/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_indices.sql
@@ -1,158 +1,98 @@
 /*netezza OMOP CDM Indices
-
   There are no unique indices created because it is assumed that the primary key constraints have been run prior to
   implementing indices.
 */
-
-
 /************************
-
 Standardized clinical data
-
 ************************/
-
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 /************************
-
 Standardized health system data
-
 ************************/
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 /************************
-
 Standardized health economics
-
 ************************/
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 /************************
-
 Standardized derived elements
-
 ************************/
-
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 /**************************
-
 Standardized meta-data
-
 ***************************/
-
 -- netezza does not support indexes
-
 /**************************
-
 Standardized vocabularies
-
 ***************************/
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
 -- netezza does not support indexes
-
 -- netezza does not support indexes
 -- netezza does not support indexes
-
-
 --Additional v6.0 indices
-
 --CREATE CLUSTERED INDEX idx_survey_person_id_1 ON @cdmDatabaseSchema.survey_conduct (person_id ASC);
-
-
 --CREATE CLUSTERED INDEX idx_episode_person_id_1 ON @cdmDatabaseSchema.episode (person_id ASC);
 --CREATE INDEX idx_episode_concept_id_1 ON @cdmDatabaseSchema.episode (episode_concept_id ASC);
-
 --CREATE CLUSTERED INDEX idx_episode_event_id_1 ON @cdmDatabaseSchema.episode_event (episode_id ASC);
 --CREATE INDEX idx_ee_field_concept_id_1 ON @cdmDatabaseSchema.episode_event (event_field_concept_id ASC);
diff --git a/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_primary_keys.sql b/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_primary_keys.sql
index fbca69d8..76db015e 100644
--- a/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_primary_keys.sql
+++ b/inst/ddl/5.4/netezza/OMOPCDM_netezza_5.4_primary_keys.sql
@@ -1,57 +1,29 @@
 --netezza CDM Primary Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT xpk_PERSON PRIMARY KEY (person_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT xpk_OBSERVATION_PERIOD PRIMARY KEY (observation_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT xpk_VISIT_OCCURRENCE PRIMARY KEY (visit_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT xpk_VISIT_DETAIL PRIMARY KEY (visit_detail_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT xpk_CONDITION_OCCURRENCE PRIMARY KEY (condition_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT xpk_DRUG_EXPOSURE PRIMARY KEY (drug_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT xpk_PROCEDURE_OCCURRENCE PRIMARY KEY (procedure_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT xpk_DEVICE_EXPOSURE PRIMARY KEY (device_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT xpk_MEASUREMENT PRIMARY KEY (measurement_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT xpk_OBSERVATION PRIMARY KEY (observation_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT xpk_NOTE PRIMARY KEY (note_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT xpk_NOTE_NLP PRIMARY KEY (note_nlp_id);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT xpk_SPECIMEN PRIMARY KEY (specimen_id);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT xpk_LOCATION PRIMARY KEY (location_id);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT xpk_CARE_SITE PRIMARY KEY (care_site_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT xpk_PROVIDER PRIMARY KEY (provider_id);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT xpk_PAYER_PLAN_PERIOD PRIMARY KEY (payer_plan_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT xpk_COST PRIMARY KEY (cost_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT xpk_DRUG_ERA PRIMARY KEY (drug_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT xpk_DOSE_ERA PRIMARY KEY (dose_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT xpk_CONDITION_ERA PRIMARY KEY (condition_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT xpk_EPISODE PRIMARY KEY (episode_id);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT xpk_METADATA PRIMARY KEY (metadata_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT xpk_CONCEPT PRIMARY KEY (concept_id);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT xpk_VOCABULARY PRIMARY KEY (vocabulary_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT xpk_DOMAIN PRIMARY KEY (domain_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT xpk_CONCEPT_CLASS PRIMARY KEY (concept_class_id);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY (relationship_id);
diff --git a/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_constraints.sql b/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_constraints.sql
index ab9b2a84..30f6fa37 100644
--- a/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_constraints.sql
+++ b/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_constraints.sql
@@ -1,353 +1,177 @@
 --oracle CDM Foreign Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_concept_id FOREIGN KEY (race_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_concept_id FOREIGN KEY (ethnicity_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_source_concept_id FOREIGN KEY (race_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_source_concept_id FOREIGN KEY (ethnicity_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_period_type_concept_id FOREIGN KEY (period_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_concept_id FOREIGN KEY (visit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_type_concept_id FOREIGN KEY (visit_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_source_concept_id FOREIGN KEY (visit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_preceding_visit_occurrence_id FOREIGN KEY (preceding_visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_concept_id FOREIGN KEY (visit_detail_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_type_concept_id FOREIGN KEY (visit_detail_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_source_concept_id FOREIGN KEY (visit_detail_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_preceding_visit_detail_id FOREIGN KEY (preceding_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_parent_visit_detail_id FOREIGN KEY (parent_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_type_concept_id FOREIGN KEY (condition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_status_concept_id FOREIGN KEY (condition_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_source_concept_id FOREIGN KEY (condition_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_type_concept_id FOREIGN KEY (drug_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_route_concept_id FOREIGN KEY (route_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_source_concept_id FOREIGN KEY (drug_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_concept_id FOREIGN KEY (procedure_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_type_concept_id FOREIGN KEY (procedure_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_modifier_concept_id FOREIGN KEY (modifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_source_concept_id FOREIGN KEY (procedure_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_concept_id FOREIGN KEY (device_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_type_concept_id FOREIGN KEY (device_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_source_concept_id FOREIGN KEY (device_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_concept_id FOREIGN KEY (measurement_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_type_concept_id FOREIGN KEY (measurement_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_operator_concept_id FOREIGN KEY (operator_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_source_concept_id FOREIGN KEY (measurement_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_meas_event_field_concept_id FOREIGN KEY (meas_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_concept_id FOREIGN KEY (observation_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_type_concept_id FOREIGN KEY (observation_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_qualifier_concept_id FOREIGN KEY (qualifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_source_concept_id FOREIGN KEY (observation_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_obs_event_field_concept_id FOREIGN KEY (obs_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_death_type_concept_id FOREIGN KEY (death_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_concept_id FOREIGN KEY (cause_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_source_concept_id FOREIGN KEY (cause_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_type_concept_id FOREIGN KEY (note_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_class_concept_id FOREIGN KEY (note_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_encoding_concept_id FOREIGN KEY (encoding_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_event_field_concept_id FOREIGN KEY (note_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_section_concept_id FOREIGN KEY (section_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_concept_id FOREIGN KEY (note_nlp_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_source_concept_id FOREIGN KEY (note_nlp_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_concept_id FOREIGN KEY (specimen_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_type_concept_id FOREIGN KEY (specimen_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_anatomic_site_concept_id FOREIGN KEY (anatomic_site_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_disease_status_concept_id FOREIGN KEY (disease_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_1 FOREIGN KEY (domain_concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_2 FOREIGN KEY (domain_concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT fpk_LOCATION_country_concept_id FOREIGN KEY (country_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_place_of_service_concept_id FOREIGN KEY (place_of_service_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_concept_id FOREIGN KEY (specialty_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_source_concept_id FOREIGN KEY (specialty_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_concept_id FOREIGN KEY (payer_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_source_concept_id FOREIGN KEY (payer_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_concept_id FOREIGN KEY (plan_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_source_concept_id FOREIGN KEY (plan_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_concept_id FOREIGN KEY (sponsor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_source_concept_id FOREIGN KEY (sponsor_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_concept_id FOREIGN KEY (stop_reason_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_source_concept_id FOREIGN KEY (stop_reason_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_domain_id FOREIGN KEY (cost_domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_type_concept_id FOREIGN KEY (cost_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_currency_concept_id FOREIGN KEY (currency_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_revenue_code_concept_id FOREIGN KEY (revenue_code_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_drg_concept_id FOREIGN KEY (drg_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_concept_id FOREIGN KEY (episode_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_object_concept_id FOREIGN KEY (episode_object_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_type_concept_id FOREIGN KEY (episode_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_source_concept_id FOREIGN KEY (episode_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_id FOREIGN KEY (episode_id) REFERENCES @cdmDatabaseSchema.EPISODE (EPISODE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_event_field_concept_id FOREIGN KEY (episode_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_concept_id FOREIGN KEY (metadata_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_type_concept_id FOREIGN KEY (metadata_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CDM_SOURCE ADD CONSTRAINT fpk_CDM_SOURCE_cdm_version_concept_id FOREIGN KEY (cdm_version_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_domain_id FOREIGN KEY (domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_vocabulary_id FOREIGN KEY (vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_concept_class_id FOREIGN KEY (concept_class_id) REFERENCES @cdmDatabaseSchema.CONCEPT_CLASS (CONCEPT_CLASS_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT fpk_VOCABULARY_vocabulary_concept_id FOREIGN KEY (vocabulary_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT fpk_DOMAIN_domain_concept_id FOREIGN KEY (domain_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT fpk_CONCEPT_CLASS_concept_class_concept_id FOREIGN KEY (concept_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_1 FOREIGN KEY (concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_2 FOREIGN KEY (concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_relationship_id FOREIGN KEY (relationship_id) REFERENCES @cdmDatabaseSchema.RELATIONSHIP (RELATIONSHIP_ID);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT fpk_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_concept_id FOREIGN KEY (concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_ancestor_concept_id FOREIGN KEY (ancestor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_descendant_concept_id FOREIGN KEY (descendant_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_source_concept_id FOREIGN KEY (source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_concept_id FOREIGN KEY (target_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_vocabulary_id FOREIGN KEY (target_vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_ingredient_concept_id FOREIGN KEY (ingredient_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_amount_unit_concept_id FOREIGN KEY (amount_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_numerator_unit_concept_id FOREIGN KEY (numerator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_denominator_unit_concept_id FOREIGN KEY (denominator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_definition_type_concept_id FOREIGN KEY (definition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_subject_concept_id FOREIGN KEY (subject_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
diff --git a/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_ddl.sql b/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_ddl.sql
index 3bf6a4a5..bc979b3b 100644
--- a/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_ddl.sql
+++ b/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_ddl.sql
@@ -1,5 +1,4 @@
 --oracle CDM DDL Specification for OMOP Common Data Model 5.4
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PERSON (
 			person_id integer NOT NULL,
@@ -20,7 +19,6 @@ CREATE TABLE @cdmDatabaseSchema.PERSON (
 			race_source_concept_id integer NULL,
 			ethnicity_source_value varchar(50) NULL,
 			ethnicity_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
 			observation_period_id integer NOT NULL,
@@ -28,7 +26,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
 			observation_period_start_date date NOT NULL,
 			observation_period_end_date date NOT NULL,
 			period_type_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
 			visit_occurrence_id integer NOT NULL,
@@ -48,7 +45,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
 			discharged_to_concept_id integer NULL,
 			discharged_to_source_value varchar(50) NULL,
 			preceding_visit_occurrence_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
 			visit_detail_id integer NOT NULL,
@@ -70,7 +66,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
 			preceding_visit_detail_id integer NULL,
 			parent_visit_detail_id integer NULL,
 			visit_occurrence_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
 			condition_occurrence_id integer NOT NULL,
@@ -89,7 +84,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
 			condition_source_value varchar(50) NULL,
 			condition_source_concept_id integer NULL,
 			condition_status_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
 			drug_exposure_id integer NOT NULL,
@@ -115,7 +109,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
 			drug_source_concept_id integer NULL,
 			route_source_value varchar(50) NULL,
 			dose_unit_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
 			procedure_occurrence_id integer NOT NULL,
@@ -134,7 +127,6 @@ CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
 			procedure_source_value varchar(50) NULL,
 			procedure_source_concept_id integer NULL,
 			modifier_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
 			device_exposure_id integer NOT NULL,
@@ -156,7 +148,6 @@ CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
 			unit_concept_id integer NULL,
 			unit_source_value varchar(50) NULL,
 			unit_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
 			measurement_id integer NOT NULL,
@@ -182,7 +173,6 @@ CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
 			value_source_value varchar(50) NULL,
 			measurement_event_id integer NULL,
 			meas_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
 			observation_id integer NOT NULL,
@@ -206,7 +196,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
 			value_source_value varchar(50) NULL,
 			observation_event_id integer NULL,
 			obs_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEATH (
 			person_id integer NOT NULL,
@@ -216,7 +205,6 @@ CREATE TABLE @cdmDatabaseSchema.DEATH (
 			cause_concept_id integer NULL,
 			cause_source_value varchar(50) NULL,
 			cause_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.NOTE (
 			note_id integer NOT NULL,
@@ -235,7 +223,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE (
 			note_source_value varchar(50) NULL,
 			note_event_id integer NULL,
 			note_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
 			note_nlp_id integer NOT NULL,
@@ -252,7 +239,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
 			term_exists varchar(1) NULL,
 			term_temporal varchar(50) NULL,
 			term_modifiers varchar(2000) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
 			specimen_id integer NOT NULL,
@@ -270,7 +256,6 @@ CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
 			unit_source_value varchar(50) NULL,
 			anatomic_site_source_value varchar(50) NULL,
 			disease_status_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
 			domain_concept_id_1 integer NOT NULL,
@@ -278,7 +263,6 @@ CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
 			domain_concept_id_2 integer NOT NULL,
 			fact_id_2 integer NOT NULL,
 			relationship_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.LOCATION (
 			location_id integer NOT NULL,
@@ -293,7 +277,6 @@ CREATE TABLE @cdmDatabaseSchema.LOCATION (
 			country_source_value varchar(80) NULL,
 			latitude float NULL,
 			longitude float NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
 			care_site_id integer NOT NULL,
@@ -302,7 +285,6 @@ CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
 			location_id integer NULL,
 			care_site_source_value varchar(50) NULL,
 			place_of_service_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.PROVIDER (
 			provider_id integer NOT NULL,
@@ -318,7 +300,6 @@ CREATE TABLE @cdmDatabaseSchema.PROVIDER (
 			specialty_source_concept_id integer NULL,
 			gender_source_value varchar(50) NULL,
 			gender_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
 			payer_plan_period_id integer NOT NULL,
@@ -338,7 +319,6 @@ CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
 			stop_reason_concept_id integer NULL,
 			stop_reason_source_value varchar(50) NULL,
 			stop_reason_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COST (
 			cost_id integer NOT NULL,
@@ -363,7 +343,6 @@ CREATE TABLE @cdmDatabaseSchema.COST (
 			revenue_code_source_value varchar(50) NULL,
 			drg_concept_id integer NULL,
 			drg_source_value varchar(3) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
 			drug_era_id integer NOT NULL,
@@ -373,7 +352,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
 			drug_era_end_date date NOT NULL,
 			drug_exposure_count integer NULL,
 			gap_days integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
 			dose_era_id integer NOT NULL,
@@ -383,7 +361,6 @@ CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
 			dose_value float NOT NULL,
 			dose_era_start_date date NOT NULL,
 			dose_era_end_date date NOT NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
 			condition_era_id integer NOT NULL,
@@ -392,7 +369,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
 			condition_era_start_date date NOT NULL,
 			condition_era_end_date date NOT NULL,
 			condition_occurrence_count integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.EPISODE (
 			episode_id integer NOT NULL,
@@ -408,13 +384,11 @@ CREATE TABLE @cdmDatabaseSchema.EPISODE (
 			episode_type_concept_id integer NOT NULL,
 			episode_source_value varchar(50) NULL,
 			episode_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT (
 			episode_id integer NOT NULL,
 			event_id integer NOT NULL,
 			episode_event_field_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.METADATA (
 			metadata_id integer NOT NULL,
@@ -426,7 +400,6 @@ CREATE TABLE @cdmDatabaseSchema.METADATA (
 			value_as_number float NULL,
 			metadata_date date NULL,
 			metadata_datetime TIMESTAMP NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
 			cdm_source_name varchar(255) NOT NULL,
@@ -440,7 +413,6 @@ CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
 			cdm_version varchar(10) NULL,
 			cdm_version_concept_id integer NOT NULL,
 			vocabulary_version varchar(20) NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT (
 			concept_id integer NOT NULL,
@@ -453,7 +425,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
 			vocabulary_id varchar(20) NOT NULL,
@@ -461,19 +432,16 @@ CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
 			vocabulary_reference varchar(255) NULL,
 			vocabulary_version varchar(255) NULL,
 			vocabulary_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DOMAIN (
 			domain_id varchar(20) NOT NULL,
 			domain_name varchar(255) NOT NULL,
 			domain_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS (
 			concept_class_id varchar(20) NOT NULL,
 			concept_class_name varchar(255) NOT NULL,
 			concept_class_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
 			concept_id_1 integer NOT NULL,
@@ -482,7 +450,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
 			relationship_id varchar(20) NOT NULL,
@@ -491,20 +458,17 @@ CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
 			defines_ancestry varchar(1) NOT NULL,
 			reverse_relationship_id varchar(20) NOT NULL,
 			relationship_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM (
 			concept_id integer NOT NULL,
 			concept_synonym_name varchar(1000) NOT NULL,
 			language_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR (
 			ancestor_concept_id integer NOT NULL,
 			descendant_concept_id integer NOT NULL,
 			min_levels_of_separation integer NOT NULL,
 			max_levels_of_separation integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
 			source_code varchar(50) NOT NULL,
@@ -516,7 +480,6 @@ CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
 			drug_concept_id integer NOT NULL,
@@ -531,14 +494,12 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT (
 			cohort_definition_id integer NOT NULL,
 			subject_id integer NOT NULL,
 			cohort_start_date date NOT NULL,
 			cohort_end_date date NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION (
 			cohort_definition_id integer NOT NULL,
diff --git a/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_indices.sql b/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_indices.sql
index dca443b9..6d17d51b 100644
--- a/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_indices.sql
+++ b/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_indices.sql
@@ -1,158 +1,98 @@
 /*oracle OMOP CDM Indices
-
   There are no unique indices created because it is assumed that the primary key constraints have been run prior to
   implementing indices.
 */
-
-
 /************************
-
 Standardized clinical data
-
 ************************/
-
 CREATE INDEX idx_person_id ON @cdmDatabaseSchema.person (person_id ASC);
 CREATE INDEX idx_gender ON @cdmDatabaseSchema.person (gender_concept_id ASC);
-
 CREATE INDEX idx_observation_period_id_1 ON @cdmDatabaseSchema.observation_period (person_id ASC);
-
 CREATE INDEX idx_visit_person_id_1 ON @cdmDatabaseSchema.visit_occurrence (person_id ASC);
 CREATE INDEX idx_visit_concept_id_1 ON @cdmDatabaseSchema.visit_occurrence (visit_concept_id ASC);
-
 CREATE INDEX idx_visit_det_person_id_1 ON @cdmDatabaseSchema.visit_detail (person_id ASC);
 CREATE INDEX idx_visit_det_concept_id_1 ON @cdmDatabaseSchema.visit_detail (visit_detail_concept_id ASC);
 CREATE INDEX idx_visit_det_occ_id ON @cdmDatabaseSchema.visit_detail (visit_occurrence_id ASC);
-
 CREATE INDEX idx_condition_person_id_1 ON @cdmDatabaseSchema.condition_occurrence (person_id ASC);
 CREATE INDEX idx_condition_concept_id_1 ON @cdmDatabaseSchema.condition_occurrence (condition_concept_id ASC);
 CREATE INDEX idx_condition_visit_id_1 ON @cdmDatabaseSchema.condition_occurrence (visit_occurrence_id ASC);
-
 CREATE INDEX idx_drug_person_id_1 ON @cdmDatabaseSchema.drug_exposure (person_id ASC);
 CREATE INDEX idx_drug_concept_id_1 ON @cdmDatabaseSchema.drug_exposure (drug_concept_id ASC);
 CREATE INDEX idx_drug_visit_id_1 ON @cdmDatabaseSchema.drug_exposure (visit_occurrence_id ASC);
-
 CREATE INDEX idx_procedure_person_id_1 ON @cdmDatabaseSchema.procedure_occurrence (person_id ASC);
 CREATE INDEX idx_procedure_concept_id_1 ON @cdmDatabaseSchema.procedure_occurrence (procedure_concept_id ASC);
 CREATE INDEX idx_procedure_visit_id_1 ON @cdmDatabaseSchema.procedure_occurrence (visit_occurrence_id ASC);
-
 CREATE INDEX idx_device_person_id_1 ON @cdmDatabaseSchema.device_exposure (person_id ASC);
 CREATE INDEX idx_device_concept_id_1 ON @cdmDatabaseSchema.device_exposure (device_concept_id ASC);
 CREATE INDEX idx_device_visit_id_1 ON @cdmDatabaseSchema.device_exposure (visit_occurrence_id ASC);
-
 CREATE INDEX idx_measurement_person_id_1 ON @cdmDatabaseSchema.measurement (person_id ASC);
 CREATE INDEX idx_measurement_concept_id_1 ON @cdmDatabaseSchema.measurement (measurement_concept_id ASC);
 CREATE INDEX idx_measurement_visit_id_1 ON @cdmDatabaseSchema.measurement (visit_occurrence_id ASC);
-
 CREATE INDEX idx_observation_person_id_1 ON @cdmDatabaseSchema.observation (person_id ASC);
 CREATE INDEX idx_observation_concept_id_1 ON @cdmDatabaseSchema.observation (observation_concept_id ASC);
 CREATE INDEX idx_observation_visit_id_1 ON @cdmDatabaseSchema.observation (visit_occurrence_id ASC);
-
 CREATE INDEX idx_death_person_id_1 ON @cdmDatabaseSchema.death (person_id ASC);
-
 CREATE INDEX idx_note_person_id_1 ON @cdmDatabaseSchema.note (person_id ASC);
 CREATE INDEX idx_note_concept_id_1 ON @cdmDatabaseSchema.note (note_type_concept_id ASC);
 CREATE INDEX idx_note_visit_id_1 ON @cdmDatabaseSchema.note (visit_occurrence_id ASC);
-
 CREATE INDEX idx_note_nlp_note_id_1 ON @cdmDatabaseSchema.note_nlp (note_id ASC);
 CREATE INDEX idx_note_nlp_concept_id_1 ON @cdmDatabaseSchema.note_nlp (note_nlp_concept_id ASC);
-
 CREATE INDEX idx_specimen_person_id_1 ON @cdmDatabaseSchema.specimen (person_id ASC);
 CREATE INDEX idx_specimen_concept_id_1 ON @cdmDatabaseSchema.specimen (specimen_concept_id ASC);
-
 CREATE INDEX idx_fact_relationship_id1 ON @cdmDatabaseSchema.fact_relationship (domain_concept_id_1 ASC);
 CREATE INDEX idx_fact_relationship_id2 ON @cdmDatabaseSchema.fact_relationship (domain_concept_id_2 ASC);
 CREATE INDEX idx_fact_relationship_id3 ON @cdmDatabaseSchema.fact_relationship (relationship_concept_id ASC);
-
 /************************
-
 Standardized health system data
-
 ************************/
-
 CREATE INDEX idx_location_id_1 ON @cdmDatabaseSchema.location (location_id ASC);
-
 CREATE INDEX idx_care_site_id_1 ON @cdmDatabaseSchema.care_site (care_site_id ASC);
-
 CREATE INDEX idx_provider_id_1 ON @cdmDatabaseSchema.provider (provider_id ASC);
-
 /************************
-
 Standardized health economics
-
 ************************/
-
 CREATE INDEX idx_period_person_id_1 ON @cdmDatabaseSchema.payer_plan_period (person_id ASC);
-
 CREATE INDEX idx_cost_event_id  ON @cdmDatabaseSchema.cost (cost_event_id ASC);
-
 /************************
-
 Standardized derived elements
-
 ************************/
-
 CREATE INDEX idx_drug_era_person_id_1 ON @cdmDatabaseSchema.drug_era (person_id ASC);
 CREATE INDEX idx_drug_era_concept_id_1 ON @cdmDatabaseSchema.drug_era (drug_concept_id ASC);
-
 CREATE INDEX idx_dose_era_person_id_1 ON @cdmDatabaseSchema.dose_era (person_id ASC);
 CREATE INDEX idx_dose_era_concept_id_1 ON @cdmDatabaseSchema.dose_era (drug_concept_id ASC);
-
 CREATE INDEX idx_condition_era_person_id_1 ON @cdmDatabaseSchema.condition_era (person_id ASC);
 CREATE INDEX idx_condition_era_concept_id_1 ON @cdmDatabaseSchema.condition_era (condition_concept_id ASC);
-
 /**************************
-
 Standardized meta-data
-
 ***************************/
-
 CREATE INDEX idx_metadata_concept_id_1 ON @cdmDatabaseSchema.metadata (metadata_concept_id ASC);
-
 /**************************
-
 Standardized vocabularies
-
 ***************************/
-
 CREATE INDEX idx_concept_concept_id ON @cdmDatabaseSchema.concept (concept_id ASC);
 CREATE INDEX idx_concept_code ON @cdmDatabaseSchema.concept (concept_code ASC);
 CREATE INDEX idx_concept_vocabluary_id ON @cdmDatabaseSchema.concept (vocabulary_id ASC);
 CREATE INDEX idx_concept_domain_id ON @cdmDatabaseSchema.concept (domain_id ASC);
 CREATE INDEX idx_concept_class_id ON @cdmDatabaseSchema.concept (concept_class_id ASC);
-
 CREATE INDEX idx_vocabulary_vocabulary_id ON @cdmDatabaseSchema.vocabulary (vocabulary_id ASC);
-
 CREATE INDEX idx_domain_domain_id ON @cdmDatabaseSchema.domain (domain_id ASC);
-
 CREATE INDEX idx_concept_class_class_id ON @cdmDatabaseSchema.concept_class (concept_class_id ASC);
-
 CREATE INDEX idx_concept_relationship_id_1 ON @cdmDatabaseSchema.concept_relationship (concept_id_1 ASC);
 CREATE INDEX idx_concept_relationship_id_2 ON @cdmDatabaseSchema.concept_relationship (concept_id_2 ASC);
 CREATE INDEX idx_concept_relationship_id_3 ON @cdmDatabaseSchema.concept_relationship (relationship_id ASC);
-
 CREATE INDEX idx_relationship_rel_id ON @cdmDatabaseSchema.relationship (relationship_id ASC);
-
 CREATE INDEX idx_concept_synonym_id ON @cdmDatabaseSchema.concept_synonym (concept_id ASC);
-
 CREATE INDEX idx_concept_ancestor_id_1 ON @cdmDatabaseSchema.concept_ancestor (ancestor_concept_id ASC);
 CREATE INDEX idx_concept_ancestor_id_2 ON @cdmDatabaseSchema.concept_ancestor (descendant_concept_id ASC);
-
 CREATE INDEX idx_source_to_concept_map_3 ON @cdmDatabaseSchema.source_to_concept_map (target_concept_id ASC);
 CREATE INDEX idx_source_to_concept_map_1 ON @cdmDatabaseSchema.source_to_concept_map (source_vocabulary_id ASC);
 CREATE INDEX idx_source_to_concept_map_2 ON @cdmDatabaseSchema.source_to_concept_map (target_vocabulary_id ASC);
 CREATE INDEX idx_source_to_concept_map_c ON @cdmDatabaseSchema.source_to_concept_map (source_code ASC);
-
 CREATE INDEX idx_drug_strength_id_1 ON @cdmDatabaseSchema.drug_strength (drug_concept_id ASC);
 CREATE INDEX idx_drug_strength_id_2 ON @cdmDatabaseSchema.drug_strength (ingredient_concept_id ASC);
-
-
 --Additional v6.0 indices
-
 --CREATE CLUSTERED INDEX idx_survey_person_id_1 ON @cdmDatabaseSchema.survey_conduct (person_id ASC);
-
-
 --CREATE CLUSTERED INDEX idx_episode_person_id_1 ON @cdmDatabaseSchema.episode (person_id ASC);
 --CREATE INDEX idx_episode_concept_id_1 ON @cdmDatabaseSchema.episode (episode_concept_id ASC);
-
 --CREATE CLUSTERED INDEX idx_episode_event_id_1 ON @cdmDatabaseSchema.episode_event (episode_id ASC);
 --CREATE INDEX idx_ee_field_concept_id_1 ON @cdmDatabaseSchema.episode_event (event_field_concept_id ASC);
diff --git a/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_primary_keys.sql b/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_primary_keys.sql
index 146e9173..862ac235 100644
--- a/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_primary_keys.sql
+++ b/inst/ddl/5.4/oracle/OMOPCDM_oracle_5.4_primary_keys.sql
@@ -1,57 +1,29 @@
 --oracle CDM Primary Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT xpk_PERSON PRIMARY KEY (person_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT xpk_OBSERVATION_PERIOD PRIMARY KEY (observation_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT xpk_VISIT_OCCURRENCE PRIMARY KEY (visit_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT xpk_VISIT_DETAIL PRIMARY KEY (visit_detail_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT xpk_CONDITION_OCCURRENCE PRIMARY KEY (condition_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT xpk_DRUG_EXPOSURE PRIMARY KEY (drug_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT xpk_PROCEDURE_OCCURRENCE PRIMARY KEY (procedure_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT xpk_DEVICE_EXPOSURE PRIMARY KEY (device_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT xpk_MEASUREMENT PRIMARY KEY (measurement_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT xpk_OBSERVATION PRIMARY KEY (observation_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT xpk_NOTE PRIMARY KEY (note_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT xpk_NOTE_NLP PRIMARY KEY (note_nlp_id);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT xpk_SPECIMEN PRIMARY KEY (specimen_id);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT xpk_LOCATION PRIMARY KEY (location_id);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT xpk_CARE_SITE PRIMARY KEY (care_site_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT xpk_PROVIDER PRIMARY KEY (provider_id);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT xpk_PAYER_PLAN_PERIOD PRIMARY KEY (payer_plan_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT xpk_COST PRIMARY KEY (cost_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT xpk_DRUG_ERA PRIMARY KEY (drug_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT xpk_DOSE_ERA PRIMARY KEY (dose_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT xpk_CONDITION_ERA PRIMARY KEY (condition_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT xpk_EPISODE PRIMARY KEY (episode_id);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT xpk_METADATA PRIMARY KEY (metadata_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT xpk_CONCEPT PRIMARY KEY (concept_id);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT xpk_VOCABULARY PRIMARY KEY (vocabulary_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT xpk_DOMAIN PRIMARY KEY (domain_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT xpk_CONCEPT_CLASS PRIMARY KEY (concept_class_id);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY (relationship_id);
diff --git a/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_constraints.sql b/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_constraints.sql
index 90e52a90..d0fcc67d 100644
--- a/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_constraints.sql
+++ b/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_constraints.sql
@@ -1,353 +1,177 @@
 --pdw CDM Foreign Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_concept_id FOREIGN KEY (race_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_concept_id FOREIGN KEY (ethnicity_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_source_concept_id FOREIGN KEY (race_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_source_concept_id FOREIGN KEY (ethnicity_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_period_type_concept_id FOREIGN KEY (period_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_concept_id FOREIGN KEY (visit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_type_concept_id FOREIGN KEY (visit_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_source_concept_id FOREIGN KEY (visit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_preceding_visit_occurrence_id FOREIGN KEY (preceding_visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_concept_id FOREIGN KEY (visit_detail_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_type_concept_id FOREIGN KEY (visit_detail_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_source_concept_id FOREIGN KEY (visit_detail_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_preceding_visit_detail_id FOREIGN KEY (preceding_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_parent_visit_detail_id FOREIGN KEY (parent_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_type_concept_id FOREIGN KEY (condition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_status_concept_id FOREIGN KEY (condition_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_source_concept_id FOREIGN KEY (condition_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_type_concept_id FOREIGN KEY (drug_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_route_concept_id FOREIGN KEY (route_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_source_concept_id FOREIGN KEY (drug_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_concept_id FOREIGN KEY (procedure_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_type_concept_id FOREIGN KEY (procedure_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_modifier_concept_id FOREIGN KEY (modifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_source_concept_id FOREIGN KEY (procedure_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_concept_id FOREIGN KEY (device_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_type_concept_id FOREIGN KEY (device_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_source_concept_id FOREIGN KEY (device_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_concept_id FOREIGN KEY (measurement_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_type_concept_id FOREIGN KEY (measurement_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_operator_concept_id FOREIGN KEY (operator_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_source_concept_id FOREIGN KEY (measurement_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_meas_event_field_concept_id FOREIGN KEY (meas_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_concept_id FOREIGN KEY (observation_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_type_concept_id FOREIGN KEY (observation_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_qualifier_concept_id FOREIGN KEY (qualifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_source_concept_id FOREIGN KEY (observation_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_obs_event_field_concept_id FOREIGN KEY (obs_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_death_type_concept_id FOREIGN KEY (death_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_concept_id FOREIGN KEY (cause_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_source_concept_id FOREIGN KEY (cause_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_type_concept_id FOREIGN KEY (note_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_class_concept_id FOREIGN KEY (note_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_encoding_concept_id FOREIGN KEY (encoding_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_event_field_concept_id FOREIGN KEY (note_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_section_concept_id FOREIGN KEY (section_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_concept_id FOREIGN KEY (note_nlp_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_source_concept_id FOREIGN KEY (note_nlp_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_concept_id FOREIGN KEY (specimen_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_type_concept_id FOREIGN KEY (specimen_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_anatomic_site_concept_id FOREIGN KEY (anatomic_site_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_disease_status_concept_id FOREIGN KEY (disease_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_1 FOREIGN KEY (domain_concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_2 FOREIGN KEY (domain_concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT fpk_LOCATION_country_concept_id FOREIGN KEY (country_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_place_of_service_concept_id FOREIGN KEY (place_of_service_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_concept_id FOREIGN KEY (specialty_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_source_concept_id FOREIGN KEY (specialty_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_concept_id FOREIGN KEY (payer_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_source_concept_id FOREIGN KEY (payer_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_concept_id FOREIGN KEY (plan_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_source_concept_id FOREIGN KEY (plan_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_concept_id FOREIGN KEY (sponsor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_source_concept_id FOREIGN KEY (sponsor_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_concept_id FOREIGN KEY (stop_reason_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_source_concept_id FOREIGN KEY (stop_reason_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_domain_id FOREIGN KEY (cost_domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_type_concept_id FOREIGN KEY (cost_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_currency_concept_id FOREIGN KEY (currency_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_revenue_code_concept_id FOREIGN KEY (revenue_code_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_drg_concept_id FOREIGN KEY (drg_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_concept_id FOREIGN KEY (episode_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_object_concept_id FOREIGN KEY (episode_object_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_type_concept_id FOREIGN KEY (episode_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_source_concept_id FOREIGN KEY (episode_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_id FOREIGN KEY (episode_id) REFERENCES @cdmDatabaseSchema.EPISODE (EPISODE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_event_field_concept_id FOREIGN KEY (episode_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_concept_id FOREIGN KEY (metadata_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_type_concept_id FOREIGN KEY (metadata_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CDM_SOURCE ADD CONSTRAINT fpk_CDM_SOURCE_cdm_version_concept_id FOREIGN KEY (cdm_version_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_domain_id FOREIGN KEY (domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_vocabulary_id FOREIGN KEY (vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_concept_class_id FOREIGN KEY (concept_class_id) REFERENCES @cdmDatabaseSchema.CONCEPT_CLASS (CONCEPT_CLASS_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT fpk_VOCABULARY_vocabulary_concept_id FOREIGN KEY (vocabulary_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT fpk_DOMAIN_domain_concept_id FOREIGN KEY (domain_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT fpk_CONCEPT_CLASS_concept_class_concept_id FOREIGN KEY (concept_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_1 FOREIGN KEY (concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_2 FOREIGN KEY (concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_relationship_id FOREIGN KEY (relationship_id) REFERENCES @cdmDatabaseSchema.RELATIONSHIP (RELATIONSHIP_ID);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT fpk_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_concept_id FOREIGN KEY (concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_ancestor_concept_id FOREIGN KEY (ancestor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_descendant_concept_id FOREIGN KEY (descendant_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_source_concept_id FOREIGN KEY (source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_concept_id FOREIGN KEY (target_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_vocabulary_id FOREIGN KEY (target_vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_ingredient_concept_id FOREIGN KEY (ingredient_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_amount_unit_concept_id FOREIGN KEY (amount_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_numerator_unit_concept_id FOREIGN KEY (numerator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_denominator_unit_concept_id FOREIGN KEY (denominator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_definition_type_concept_id FOREIGN KEY (definition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_subject_concept_id FOREIGN KEY (subject_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
diff --git a/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_ddl.sql b/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_ddl.sql
index 418f4bcc..1b88a957 100644
--- a/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_ddl.sql
+++ b/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_ddl.sql
@@ -1,7 +1,6 @@
 --pdw CDM DDL Specification for OMOP Common Data Model 5.4
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.PERSON  ( person_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.PERSON  ( person_id integer NOT NULL,
 			gender_concept_id integer NOT NULL,
 			year_of_birth integer NOT NULL,
 			month_of_birth integer NULL,
@@ -20,17 +19,15 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.PERSON  ( person_id
 			ethnicity_source_value varchar(50) NULL,
 			ethnicity_source_concept_id integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.OBSERVATION_PERIOD  (observation_period_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD  (observation_period_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			observation_period_start_date date NOT NULL,
 			observation_period_end_date date NOT NULL,
 			period_type_concept_id integer NOT NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.VISIT_OCCURRENCE  (visit_occurrence_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE  (visit_occurrence_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			visit_concept_id integer NOT NULL,
 			visit_start_date date NOT NULL,
@@ -48,9 +45,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.VISIT_OCCURRENCE  (
 			discharged_to_source_value varchar(50) NULL,
 			preceding_visit_occurrence_id integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.VISIT_DETAIL  (visit_detail_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL  (visit_detail_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			visit_detail_concept_id integer NOT NULL,
 			visit_detail_start_date date NOT NULL,
@@ -70,9 +66,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.VISIT_DETAIL  (visi
 			parent_visit_detail_id integer NULL,
 			visit_occurrence_id integer NOT NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CONDITION_OCCURRENCE  (condition_occurrence_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE  (condition_occurrence_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			condition_concept_id integer NOT NULL,
 			condition_start_date date NOT NULL,
@@ -89,9 +84,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CONDITION_OCCURRENC
 			condition_source_concept_id integer NULL,
 			condition_status_source_value varchar(50) NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DRUG_EXPOSURE  (drug_exposure_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE  (drug_exposure_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			drug_concept_id integer NOT NULL,
 			drug_exposure_start_date date NOT NULL,
@@ -115,9 +109,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DRUG_EXPOSURE  (dru
 			route_source_value varchar(50) NULL,
 			dose_unit_source_value varchar(50) NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.PROCEDURE_OCCURRENCE  (procedure_occurrence_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE  (procedure_occurrence_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			procedure_concept_id integer NOT NULL,
 			procedure_date date NOT NULL,
@@ -134,9 +127,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.PROCEDURE_OCCURRENC
 			procedure_source_concept_id integer NULL,
 			modifier_source_value varchar(50) NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DEVICE_EXPOSURE  (device_exposure_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE  (device_exposure_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			device_concept_id integer NOT NULL,
 			device_exposure_start_date date NOT NULL,
@@ -156,9 +148,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DEVICE_EXPOSURE  (d
 			unit_source_value varchar(50) NULL,
 			unit_source_concept_id integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.MEASUREMENT  (measurement_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.MEASUREMENT  (measurement_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			measurement_concept_id integer NOT NULL,
 			measurement_date date NOT NULL,
@@ -182,9 +173,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.MEASUREMENT  (measu
 			measurement_event_id integer NULL,
 			meas_event_field_concept_id integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.OBSERVATION  (observation_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.OBSERVATION  (observation_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			observation_concept_id integer NOT NULL,
 			observation_date date NOT NULL,
@@ -206,9 +196,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.OBSERVATION  (obser
 			observation_event_id integer NULL,
 			obs_event_field_concept_id integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DEATH  ( person_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.DEATH  ( person_id integer NOT NULL,
 			death_date date NOT NULL,
 			death_datetime datetime NULL,
 			death_type_concept_id integer NULL,
@@ -216,9 +205,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DEATH  ( person_id
 			cause_source_value varchar(50) NULL,
 			cause_source_concept_id integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.NOTE  (note_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.NOTE  (note_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			note_date date NOT NULL,
 			note_datetime datetime NULL,
@@ -235,9 +223,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.NOTE  (note_id inte
 			note_event_id integer NULL,
 			note_event_field_concept_id integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.NOTE_NLP  (note_nlp_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.NOTE_NLP  (note_nlp_id integer NOT NULL,
 			note_id integer NOT NULL,
 			section_concept_id integer NULL,
 			snippet varchar(250) NULL,
@@ -252,9 +239,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.NOTE_NLP  (note_nlp
 			term_temporal varchar(50) NULL,
 			term_modifiers varchar(2000) NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.SPECIMEN  (specimen_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.SPECIMEN  (specimen_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			specimen_concept_id integer NOT NULL,
 			specimen_type_concept_id integer NOT NULL,
@@ -270,17 +256,15 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.SPECIMEN  (specimen
 			anatomic_site_source_value varchar(50) NULL,
 			disease_status_source_value varchar(50) NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.FACT_RELATIONSHIP  (domain_concept_id_1 integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP  (domain_concept_id_1 integer NOT NULL,
 			fact_id_1 integer NOT NULL,
 			domain_concept_id_2 integer NOT NULL,
 			fact_id_2 integer NOT NULL,
 			relationship_concept_id integer NOT NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.LOCATION  (location_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.LOCATION  (location_id integer NOT NULL,
 			address_1 varchar(50) NULL,
 			address_2 varchar(50) NULL,
 			city varchar(50) NULL,
@@ -293,18 +277,16 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.LOCATION  (location
 			latitude float NULL,
 			longitude float NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CARE_SITE  (care_site_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.CARE_SITE  (care_site_id integer NOT NULL,
 			care_site_name varchar(255) NULL,
 			place_of_service_concept_id integer NULL,
 			location_id integer NULL,
 			care_site_source_value varchar(50) NULL,
 			place_of_service_source_value varchar(50) NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.PROVIDER  (provider_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.PROVIDER  (provider_id integer NOT NULL,
 			provider_name varchar(255) NULL,
 			npi varchar(20) NULL,
 			dea varchar(20) NULL,
@@ -318,9 +300,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.PROVIDER  (provider
 			gender_source_value varchar(50) NULL,
 			gender_source_concept_id integer NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.PAYER_PLAN_PERIOD  (payer_plan_period_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD  (payer_plan_period_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			payer_plan_period_start_date date NOT NULL,
 			payer_plan_period_end_date date NOT NULL,
@@ -338,9 +319,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.PAYER_PLAN_PERIOD
 			stop_reason_source_value varchar(50) NULL,
 			stop_reason_source_concept_id integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.COST  (cost_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.COST  (cost_id integer NOT NULL,
 			cost_event_id integer NOT NULL,
 			cost_domain_id varchar(20) NOT NULL,
 			cost_type_concept_id integer NOT NULL,
@@ -363,9 +343,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.COST  (cost_id inte
 			drg_concept_id integer NULL,
 			drg_source_value varchar(3) NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DRUG_ERA  (drug_era_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.DRUG_ERA  (drug_era_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			drug_concept_id integer NOT NULL,
 			drug_era_start_date date NOT NULL,
@@ -373,9 +352,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DRUG_ERA  (drug_era
 			drug_exposure_count integer NULL,
 			gap_days integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DOSE_ERA  (dose_era_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.DOSE_ERA  (dose_era_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			drug_concept_id integer NOT NULL,
 			unit_concept_id integer NOT NULL,
@@ -383,18 +361,16 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DOSE_ERA  (dose_era
 			dose_era_start_date date NOT NULL,
 			dose_era_end_date date NOT NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CONDITION_ERA  (condition_era_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA  (condition_era_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			condition_concept_id integer NOT NULL,
 			condition_era_start_date date NOT NULL,
 			condition_era_end_date date NOT NULL,
 			condition_occurrence_count integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON KEY (person_id)
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.EPISODE  (episode_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.EPISODE  (episode_id integer NOT NULL,
 			 person_id integer NOT NULL,
 			episode_concept_id integer NOT NULL,
 			episode_start_date date NOT NULL,
@@ -408,15 +384,13 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.EPISODE  (episode_i
 			episode_source_value varchar(50) NULL,
 			episode_source_concept_id integer NULL )
 WITH (DISTRIBUTION = HASH(person_id));
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.EPISODE_EVENT  (episode_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT  (episode_id integer NOT NULL,
 			event_id integer NOT NULL,
 			episode_event_field_concept_id integer NOT NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.METADATA  (metadata_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.METADATA  (metadata_id integer NOT NULL,
 			metadata_concept_id integer NOT NULL,
 			metadata_type_concept_id integer NOT NULL,
 			name varchar(250) NOT NULL,
@@ -426,9 +400,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.METADATA  (metadata
 			metadata_date date NULL,
 			metadata_datetime datetime NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CDM_SOURCE  (cdm_source_name varchar(255) NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE  (cdm_source_name varchar(255) NOT NULL,
 			cdm_source_abbreviation varchar(25) NOT NULL,
 			cdm_holder varchar(255) NOT NULL,
 			source_description VARCHAR(1000) NULL,
@@ -440,9 +413,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CDM_SOURCE  (cdm_so
 			cdm_version_concept_id integer NOT NULL,
 			vocabulary_version varchar(20) NOT NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CONCEPT  (concept_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.CONCEPT  (concept_id integer NOT NULL,
 			concept_name varchar(255) NOT NULL,
 			domain_id varchar(20) NOT NULL,
 			vocabulary_id varchar(20) NOT NULL,
@@ -453,60 +425,52 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CONCEPT  (concept_i
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.VOCABULARY  (vocabulary_id varchar(20) NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.VOCABULARY  (vocabulary_id varchar(20) NOT NULL,
 			vocabulary_name varchar(255) NOT NULL,
 			vocabulary_reference varchar(255) NULL,
 			vocabulary_version varchar(255) NULL,
 			vocabulary_concept_id integer NOT NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DOMAIN  (domain_id varchar(20) NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.DOMAIN  (domain_id varchar(20) NOT NULL,
 			domain_name varchar(255) NOT NULL,
 			domain_concept_id integer NOT NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CONCEPT_CLASS  (concept_class_id varchar(20) NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS  (concept_class_id varchar(20) NOT NULL,
 			concept_class_name varchar(255) NOT NULL,
 			concept_class_concept_id integer NOT NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CONCEPT_RELATIONSHIP  (concept_id_1 integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP  (concept_id_1 integer NOT NULL,
 			concept_id_2 integer NOT NULL,
 			relationship_id varchar(20) NOT NULL,
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.RELATIONSHIP  (relationship_id varchar(20) NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP  (relationship_id varchar(20) NOT NULL,
 			relationship_name varchar(255) NOT NULL,
 			is_hierarchical varchar(1) NOT NULL,
 			defines_ancestry varchar(1) NOT NULL,
 			reverse_relationship_id varchar(20) NOT NULL,
 			relationship_concept_id integer NOT NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CONCEPT_SYNONYM  (concept_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM  (concept_id integer NOT NULL,
 			concept_synonym_name varchar(1000) NOT NULL,
 			language_concept_id integer NOT NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.CONCEPT_ANCESTOR  (ancestor_concept_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR  (ancestor_concept_id integer NOT NULL,
 			descendant_concept_id integer NOT NULL,
 			min_levels_of_separation integer NOT NULL,
 			max_levels_of_separation integer NOT NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP  (source_code varchar(50) NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP  (source_code varchar(50) NOT NULL,
 			source_concept_id integer NOT NULL,
 			source_vocabulary_id varchar(20) NOT NULL,
 			source_code_description varchar(255) NULL,
@@ -516,9 +480,8 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.SOURCE_TO_CONCEPT_M
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DRUG_STRENGTH  (drug_concept_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH  (drug_concept_id integer NOT NULL,
 			ingredient_concept_id integer NOT NULL,
 			amount_value float NULL,
 			amount_unit_concept_id integer NULL,
@@ -531,16 +494,14 @@ IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.DRUG_STRENGTH  (dru
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL )
 WITH (DISTRIBUTION = REPLICATE);
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.COHORT  (cohort_definition_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.COHORT  (cohort_definition_id integer NOT NULL,
 			 subject_id integer NOT NULL,
 			cohort_start_date date NOT NULL,
 			cohort_end_date date NOT NULL )
 WITH (DISTRIBUTION = HASH(subject_id));
-
 --HINT DISTRIBUTE ON RANDOM
-IF XACT_STATE() = 1 COMMIT; CREATE TABLE  @cdmDatabaseSchema.COHORT_DEFINITION  (cohort_definition_id integer NOT NULL,
+IF XACT_STATE() = 1 COMMIT; CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION  (cohort_definition_id integer NOT NULL,
 			cohort_definition_name varchar(255) NOT NULL,
 			cohort_definition_description VARCHAR(1000) NULL,
 			definition_type_concept_id integer NOT NULL,
diff --git a/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_indices.sql b/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_indices.sql
index d45a1d3e..7aa23b75 100644
--- a/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_indices.sql
+++ b/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_indices.sql
@@ -1,158 +1,98 @@
 /*pdw OMOP CDM Indices
-
   There are no unique indices created because it is assumed that the primary key constraints have been run prior to
   implementing indices.
 */
-
-
 /************************
-
 Standardized clinical data
-
 ************************/
-
 CREATE CLUSTERED INDEX idx_person_id ON @cdmDatabaseSchema.person (person_id ASC);
 CREATE INDEX idx_gender ON @cdmDatabaseSchema.person (gender_concept_id ASC);
-
 CREATE CLUSTERED INDEX idx_observation_period_id_1 ON @cdmDatabaseSchema.observation_period (person_id ASC);
-
 CREATE CLUSTERED INDEX idx_visit_person_id_1 ON @cdmDatabaseSchema.visit_occurrence (person_id ASC);
 CREATE INDEX idx_visit_concept_id_1 ON @cdmDatabaseSchema.visit_occurrence (visit_concept_id ASC);
-
 CREATE CLUSTERED INDEX idx_visit_det_person_id_1 ON @cdmDatabaseSchema.visit_detail (person_id ASC);
 CREATE INDEX idx_visit_det_concept_id_1 ON @cdmDatabaseSchema.visit_detail (visit_detail_concept_id ASC);
 CREATE INDEX idx_visit_det_occ_id ON @cdmDatabaseSchema.visit_detail (visit_occurrence_id ASC);
-
 CREATE CLUSTERED INDEX idx_condition_person_id_1 ON @cdmDatabaseSchema.condition_occurrence (person_id ASC);
 CREATE INDEX idx_condition_concept_id_1 ON @cdmDatabaseSchema.condition_occurrence (condition_concept_id ASC);
 CREATE INDEX idx_condition_visit_id_1 ON @cdmDatabaseSchema.condition_occurrence (visit_occurrence_id ASC);
-
 CREATE CLUSTERED INDEX idx_drug_person_id_1 ON @cdmDatabaseSchema.drug_exposure (person_id ASC);
 CREATE INDEX idx_drug_concept_id_1 ON @cdmDatabaseSchema.drug_exposure (drug_concept_id ASC);
 CREATE INDEX idx_drug_visit_id_1 ON @cdmDatabaseSchema.drug_exposure (visit_occurrence_id ASC);
-
 CREATE CLUSTERED INDEX idx_procedure_person_id_1 ON @cdmDatabaseSchema.procedure_occurrence (person_id ASC);
 CREATE INDEX idx_procedure_concept_id_1 ON @cdmDatabaseSchema.procedure_occurrence (procedure_concept_id ASC);
 CREATE INDEX idx_procedure_visit_id_1 ON @cdmDatabaseSchema.procedure_occurrence (visit_occurrence_id ASC);
-
 CREATE CLUSTERED INDEX idx_device_person_id_1 ON @cdmDatabaseSchema.device_exposure (person_id ASC);
 CREATE INDEX idx_device_concept_id_1 ON @cdmDatabaseSchema.device_exposure (device_concept_id ASC);
 CREATE INDEX idx_device_visit_id_1 ON @cdmDatabaseSchema.device_exposure (visit_occurrence_id ASC);
-
 CREATE CLUSTERED INDEX idx_measurement_person_id_1 ON @cdmDatabaseSchema.measurement (person_id ASC);
 CREATE INDEX idx_measurement_concept_id_1 ON @cdmDatabaseSchema.measurement (measurement_concept_id ASC);
 CREATE INDEX idx_measurement_visit_id_1 ON @cdmDatabaseSchema.measurement (visit_occurrence_id ASC);
-
 CREATE CLUSTERED INDEX idx_observation_person_id_1 ON @cdmDatabaseSchema.observation (person_id ASC);
 CREATE INDEX idx_observation_concept_id_1 ON @cdmDatabaseSchema.observation (observation_concept_id ASC);
 CREATE INDEX idx_observation_visit_id_1 ON @cdmDatabaseSchema.observation (visit_occurrence_id ASC);
-
 CREATE CLUSTERED INDEX idx_death_person_id_1 ON @cdmDatabaseSchema.death (person_id ASC);
-
 CREATE CLUSTERED INDEX idx_note_person_id_1 ON @cdmDatabaseSchema.note (person_id ASC);
 CREATE INDEX idx_note_concept_id_1 ON @cdmDatabaseSchema.note (note_type_concept_id ASC);
 CREATE INDEX idx_note_visit_id_1 ON @cdmDatabaseSchema.note (visit_occurrence_id ASC);
-
 CREATE CLUSTERED INDEX idx_note_nlp_note_id_1 ON @cdmDatabaseSchema.note_nlp (note_id ASC);
 CREATE INDEX idx_note_nlp_concept_id_1 ON @cdmDatabaseSchema.note_nlp (note_nlp_concept_id ASC);
-
 CREATE CLUSTERED INDEX idx_specimen_person_id_1 ON @cdmDatabaseSchema.specimen (person_id ASC);
 CREATE INDEX idx_specimen_concept_id_1 ON @cdmDatabaseSchema.specimen (specimen_concept_id ASC);
-
 CREATE INDEX idx_fact_relationship_id1 ON @cdmDatabaseSchema.fact_relationship (domain_concept_id_1 ASC);
 CREATE INDEX idx_fact_relationship_id2 ON @cdmDatabaseSchema.fact_relationship (domain_concept_id_2 ASC);
 CREATE INDEX idx_fact_relationship_id3 ON @cdmDatabaseSchema.fact_relationship (relationship_concept_id ASC);
-
 /************************
-
 Standardized health system data
-
 ************************/
-
 CREATE CLUSTERED INDEX idx_location_id_1 ON @cdmDatabaseSchema.location (location_id ASC);
-
 CREATE CLUSTERED INDEX idx_care_site_id_1 ON @cdmDatabaseSchema.care_site (care_site_id ASC);
-
 CREATE CLUSTERED INDEX idx_provider_id_1 ON @cdmDatabaseSchema.provider (provider_id ASC);
-
 /************************
-
 Standardized health economics
-
 ************************/
-
 CREATE CLUSTERED INDEX idx_period_person_id_1 ON @cdmDatabaseSchema.payer_plan_period (person_id ASC);
-
 CREATE INDEX idx_cost_event_id  ON @cdmDatabaseSchema.cost (cost_event_id ASC);
-
 /************************
-
 Standardized derived elements
-
 ************************/
-
 CREATE CLUSTERED INDEX idx_drug_era_person_id_1 ON @cdmDatabaseSchema.drug_era (person_id ASC);
 CREATE INDEX idx_drug_era_concept_id_1 ON @cdmDatabaseSchema.drug_era (drug_concept_id ASC);
-
 CREATE CLUSTERED INDEX idx_dose_era_person_id_1 ON @cdmDatabaseSchema.dose_era (person_id ASC);
 CREATE INDEX idx_dose_era_concept_id_1 ON @cdmDatabaseSchema.dose_era (drug_concept_id ASC);
-
 CREATE CLUSTERED INDEX idx_condition_era_person_id_1 ON @cdmDatabaseSchema.condition_era (person_id ASC);
 CREATE INDEX idx_condition_era_concept_id_1 ON @cdmDatabaseSchema.condition_era (condition_concept_id ASC);
-
 /**************************
-
 Standardized meta-data
-
 ***************************/
-
 CREATE CLUSTERED INDEX idx_metadata_concept_id_1 ON @cdmDatabaseSchema.metadata (metadata_concept_id ASC);
-
 /**************************
-
 Standardized vocabularies
-
 ***************************/
-
 CREATE CLUSTERED INDEX idx_concept_concept_id ON @cdmDatabaseSchema.concept (concept_id ASC);
 CREATE INDEX idx_concept_code ON @cdmDatabaseSchema.concept (concept_code ASC);
 CREATE INDEX idx_concept_vocabluary_id ON @cdmDatabaseSchema.concept (vocabulary_id ASC);
 CREATE INDEX idx_concept_domain_id ON @cdmDatabaseSchema.concept (domain_id ASC);
 CREATE INDEX idx_concept_class_id ON @cdmDatabaseSchema.concept (concept_class_id ASC);
-
 CREATE CLUSTERED INDEX idx_vocabulary_vocabulary_id ON @cdmDatabaseSchema.vocabulary (vocabulary_id ASC);
-
 CREATE CLUSTERED INDEX idx_domain_domain_id ON @cdmDatabaseSchema.domain (domain_id ASC);
-
 CREATE CLUSTERED INDEX idx_concept_class_class_id ON @cdmDatabaseSchema.concept_class (concept_class_id ASC);
-
 CREATE CLUSTERED INDEX idx_concept_relationship_id_1 ON @cdmDatabaseSchema.concept_relationship (concept_id_1 ASC);
 CREATE INDEX idx_concept_relationship_id_2 ON @cdmDatabaseSchema.concept_relationship (concept_id_2 ASC);
 CREATE INDEX idx_concept_relationship_id_3 ON @cdmDatabaseSchema.concept_relationship (relationship_id ASC);
-
 CREATE CLUSTERED INDEX idx_relationship_rel_id ON @cdmDatabaseSchema.relationship (relationship_id ASC);
-
 CREATE CLUSTERED INDEX idx_concept_synonym_id ON @cdmDatabaseSchema.concept_synonym (concept_id ASC);
-
 CREATE CLUSTERED INDEX idx_concept_ancestor_id_1 ON @cdmDatabaseSchema.concept_ancestor (ancestor_concept_id ASC);
 CREATE INDEX idx_concept_ancestor_id_2 ON @cdmDatabaseSchema.concept_ancestor (descendant_concept_id ASC);
-
 CREATE CLUSTERED INDEX idx_source_to_concept_map_3 ON @cdmDatabaseSchema.source_to_concept_map (target_concept_id ASC);
 CREATE INDEX idx_source_to_concept_map_1 ON @cdmDatabaseSchema.source_to_concept_map (source_vocabulary_id ASC);
 CREATE INDEX idx_source_to_concept_map_2 ON @cdmDatabaseSchema.source_to_concept_map (target_vocabulary_id ASC);
 CREATE INDEX idx_source_to_concept_map_c ON @cdmDatabaseSchema.source_to_concept_map (source_code ASC);
-
 CREATE CLUSTERED INDEX idx_drug_strength_id_1 ON @cdmDatabaseSchema.drug_strength (drug_concept_id ASC);
 CREATE INDEX idx_drug_strength_id_2 ON @cdmDatabaseSchema.drug_strength (ingredient_concept_id ASC);
-
-
 --Additional v6.0 indices
-
 --CREATE CLUSTERED INDEX idx_survey_person_id_1 ON @cdmDatabaseSchema.survey_conduct (person_id ASC);
-
-
 --CREATE CLUSTERED INDEX idx_episode_person_id_1 ON @cdmDatabaseSchema.episode (person_id ASC);
 --CREATE INDEX idx_episode_concept_id_1 ON @cdmDatabaseSchema.episode (episode_concept_id ASC);
-
 --CREATE CLUSTERED INDEX idx_episode_event_id_1 ON @cdmDatabaseSchema.episode_event (episode_id ASC);
 --CREATE INDEX idx_ee_field_concept_id_1 ON @cdmDatabaseSchema.episode_event (event_field_concept_id ASC);
diff --git a/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_primary_keys.sql b/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_primary_keys.sql
index e2324205..83c9a51a 100644
--- a/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_primary_keys.sql
+++ b/inst/ddl/5.4/pdw/OMOPCDM_pdw_5.4_primary_keys.sql
@@ -1,57 +1,29 @@
 --pdw CDM Primary Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT xpk_PERSON PRIMARY KEY NONCLUSTERED (person_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT xpk_OBSERVATION_PERIOD PRIMARY KEY NONCLUSTERED (observation_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT xpk_VISIT_OCCURRENCE PRIMARY KEY NONCLUSTERED (visit_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT xpk_VISIT_DETAIL PRIMARY KEY NONCLUSTERED (visit_detail_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT xpk_CONDITION_OCCURRENCE PRIMARY KEY NONCLUSTERED (condition_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT xpk_DRUG_EXPOSURE PRIMARY KEY NONCLUSTERED (drug_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT xpk_PROCEDURE_OCCURRENCE PRIMARY KEY NONCLUSTERED (procedure_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT xpk_DEVICE_EXPOSURE PRIMARY KEY NONCLUSTERED (device_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT xpk_MEASUREMENT PRIMARY KEY NONCLUSTERED (measurement_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT xpk_OBSERVATION PRIMARY KEY NONCLUSTERED (observation_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT xpk_NOTE PRIMARY KEY NONCLUSTERED (note_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT xpk_NOTE_NLP PRIMARY KEY NONCLUSTERED (note_nlp_id);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT xpk_SPECIMEN PRIMARY KEY NONCLUSTERED (specimen_id);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT xpk_LOCATION PRIMARY KEY NONCLUSTERED (location_id);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT xpk_CARE_SITE PRIMARY KEY NONCLUSTERED (care_site_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT xpk_PROVIDER PRIMARY KEY NONCLUSTERED (provider_id);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT xpk_PAYER_PLAN_PERIOD PRIMARY KEY NONCLUSTERED (payer_plan_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT xpk_COST PRIMARY KEY NONCLUSTERED (cost_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT xpk_DRUG_ERA PRIMARY KEY NONCLUSTERED (drug_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT xpk_DOSE_ERA PRIMARY KEY NONCLUSTERED (dose_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT xpk_CONDITION_ERA PRIMARY KEY NONCLUSTERED (condition_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT xpk_EPISODE PRIMARY KEY NONCLUSTERED (episode_id);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT xpk_METADATA PRIMARY KEY NONCLUSTERED (metadata_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT xpk_CONCEPT PRIMARY KEY NONCLUSTERED (concept_id);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT xpk_VOCABULARY PRIMARY KEY NONCLUSTERED (vocabulary_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT xpk_DOMAIN PRIMARY KEY NONCLUSTERED (domain_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT xpk_CONCEPT_CLASS PRIMARY KEY NONCLUSTERED (concept_class_id);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY NONCLUSTERED (relationship_id);
diff --git a/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_constraints.sql b/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_constraints.sql
index 763a0f76..a06b92e3 100644
--- a/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_constraints.sql
+++ b/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_constraints.sql
@@ -1,353 +1,177 @@
 --postgresql CDM Foreign Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_concept_id FOREIGN KEY (race_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_concept_id FOREIGN KEY (ethnicity_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_source_concept_id FOREIGN KEY (race_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_source_concept_id FOREIGN KEY (ethnicity_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_period_type_concept_id FOREIGN KEY (period_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_concept_id FOREIGN KEY (visit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_type_concept_id FOREIGN KEY (visit_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_source_concept_id FOREIGN KEY (visit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_preceding_visit_occurrence_id FOREIGN KEY (preceding_visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_concept_id FOREIGN KEY (visit_detail_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_type_concept_id FOREIGN KEY (visit_detail_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_source_concept_id FOREIGN KEY (visit_detail_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_preceding_visit_detail_id FOREIGN KEY (preceding_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_parent_visit_detail_id FOREIGN KEY (parent_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_type_concept_id FOREIGN KEY (condition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_status_concept_id FOREIGN KEY (condition_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_source_concept_id FOREIGN KEY (condition_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_type_concept_id FOREIGN KEY (drug_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_route_concept_id FOREIGN KEY (route_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_source_concept_id FOREIGN KEY (drug_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_concept_id FOREIGN KEY (procedure_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_type_concept_id FOREIGN KEY (procedure_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_modifier_concept_id FOREIGN KEY (modifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_source_concept_id FOREIGN KEY (procedure_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_concept_id FOREIGN KEY (device_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_type_concept_id FOREIGN KEY (device_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_source_concept_id FOREIGN KEY (device_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_concept_id FOREIGN KEY (measurement_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_type_concept_id FOREIGN KEY (measurement_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_operator_concept_id FOREIGN KEY (operator_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_source_concept_id FOREIGN KEY (measurement_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_meas_event_field_concept_id FOREIGN KEY (meas_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_concept_id FOREIGN KEY (observation_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_type_concept_id FOREIGN KEY (observation_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_qualifier_concept_id FOREIGN KEY (qualifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_source_concept_id FOREIGN KEY (observation_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_obs_event_field_concept_id FOREIGN KEY (obs_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_death_type_concept_id FOREIGN KEY (death_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_concept_id FOREIGN KEY (cause_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_source_concept_id FOREIGN KEY (cause_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_type_concept_id FOREIGN KEY (note_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_class_concept_id FOREIGN KEY (note_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_encoding_concept_id FOREIGN KEY (encoding_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_event_field_concept_id FOREIGN KEY (note_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_section_concept_id FOREIGN KEY (section_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_concept_id FOREIGN KEY (note_nlp_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_source_concept_id FOREIGN KEY (note_nlp_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_concept_id FOREIGN KEY (specimen_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_type_concept_id FOREIGN KEY (specimen_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_anatomic_site_concept_id FOREIGN KEY (anatomic_site_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_disease_status_concept_id FOREIGN KEY (disease_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_1 FOREIGN KEY (domain_concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_2 FOREIGN KEY (domain_concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT fpk_LOCATION_country_concept_id FOREIGN KEY (country_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_place_of_service_concept_id FOREIGN KEY (place_of_service_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_concept_id FOREIGN KEY (specialty_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_source_concept_id FOREIGN KEY (specialty_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_concept_id FOREIGN KEY (payer_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_source_concept_id FOREIGN KEY (payer_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_concept_id FOREIGN KEY (plan_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_source_concept_id FOREIGN KEY (plan_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_concept_id FOREIGN KEY (sponsor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_source_concept_id FOREIGN KEY (sponsor_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_concept_id FOREIGN KEY (stop_reason_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_source_concept_id FOREIGN KEY (stop_reason_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_domain_id FOREIGN KEY (cost_domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_type_concept_id FOREIGN KEY (cost_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_currency_concept_id FOREIGN KEY (currency_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_revenue_code_concept_id FOREIGN KEY (revenue_code_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_drg_concept_id FOREIGN KEY (drg_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_concept_id FOREIGN KEY (episode_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_object_concept_id FOREIGN KEY (episode_object_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_type_concept_id FOREIGN KEY (episode_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_source_concept_id FOREIGN KEY (episode_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_id FOREIGN KEY (episode_id) REFERENCES @cdmDatabaseSchema.EPISODE (EPISODE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_event_field_concept_id FOREIGN KEY (episode_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_concept_id FOREIGN KEY (metadata_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_type_concept_id FOREIGN KEY (metadata_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CDM_SOURCE ADD CONSTRAINT fpk_CDM_SOURCE_cdm_version_concept_id FOREIGN KEY (cdm_version_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_domain_id FOREIGN KEY (domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_vocabulary_id FOREIGN KEY (vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_concept_class_id FOREIGN KEY (concept_class_id) REFERENCES @cdmDatabaseSchema.CONCEPT_CLASS (CONCEPT_CLASS_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT fpk_VOCABULARY_vocabulary_concept_id FOREIGN KEY (vocabulary_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT fpk_DOMAIN_domain_concept_id FOREIGN KEY (domain_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT fpk_CONCEPT_CLASS_concept_class_concept_id FOREIGN KEY (concept_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_1 FOREIGN KEY (concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_2 FOREIGN KEY (concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_relationship_id FOREIGN KEY (relationship_id) REFERENCES @cdmDatabaseSchema.RELATIONSHIP (RELATIONSHIP_ID);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT fpk_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_concept_id FOREIGN KEY (concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_ancestor_concept_id FOREIGN KEY (ancestor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_descendant_concept_id FOREIGN KEY (descendant_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_source_concept_id FOREIGN KEY (source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_concept_id FOREIGN KEY (target_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_vocabulary_id FOREIGN KEY (target_vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_ingredient_concept_id FOREIGN KEY (ingredient_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_amount_unit_concept_id FOREIGN KEY (amount_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_numerator_unit_concept_id FOREIGN KEY (numerator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_denominator_unit_concept_id FOREIGN KEY (denominator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_definition_type_concept_id FOREIGN KEY (definition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_subject_concept_id FOREIGN KEY (subject_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
diff --git a/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_ddl.sql b/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_ddl.sql
index 564d7d80..12c61d2c 100644
--- a/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_ddl.sql
+++ b/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_ddl.sql
@@ -1,5 +1,4 @@
 --postgresql CDM DDL Specification for OMOP Common Data Model 5.4
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PERSON (
 			person_id integer NOT NULL,
@@ -20,7 +19,6 @@ CREATE TABLE @cdmDatabaseSchema.PERSON (
 			race_source_concept_id integer NULL,
 			ethnicity_source_value varchar(50) NULL,
 			ethnicity_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
 			observation_period_id integer NOT NULL,
@@ -28,7 +26,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
 			observation_period_start_date date NOT NULL,
 			observation_period_end_date date NOT NULL,
 			period_type_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
 			visit_occurrence_id integer NOT NULL,
@@ -48,7 +45,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
 			discharged_to_concept_id integer NULL,
 			discharged_to_source_value varchar(50) NULL,
 			preceding_visit_occurrence_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
 			visit_detail_id integer NOT NULL,
@@ -70,7 +66,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
 			preceding_visit_detail_id integer NULL,
 			parent_visit_detail_id integer NULL,
 			visit_occurrence_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
 			condition_occurrence_id integer NOT NULL,
@@ -89,7 +84,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
 			condition_source_value varchar(50) NULL,
 			condition_source_concept_id integer NULL,
 			condition_status_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
 			drug_exposure_id integer NOT NULL,
@@ -115,7 +109,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
 			drug_source_concept_id integer NULL,
 			route_source_value varchar(50) NULL,
 			dose_unit_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
 			procedure_occurrence_id integer NOT NULL,
@@ -134,7 +127,6 @@ CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
 			procedure_source_value varchar(50) NULL,
 			procedure_source_concept_id integer NULL,
 			modifier_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
 			device_exposure_id integer NOT NULL,
@@ -156,7 +148,6 @@ CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
 			unit_concept_id integer NULL,
 			unit_source_value varchar(50) NULL,
 			unit_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
 			measurement_id integer NOT NULL,
@@ -182,7 +173,6 @@ CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
 			value_source_value varchar(50) NULL,
 			measurement_event_id integer NULL,
 			meas_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
 			observation_id integer NOT NULL,
@@ -206,7 +196,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
 			value_source_value varchar(50) NULL,
 			observation_event_id integer NULL,
 			obs_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEATH (
 			person_id integer NOT NULL,
@@ -216,7 +205,6 @@ CREATE TABLE @cdmDatabaseSchema.DEATH (
 			cause_concept_id integer NULL,
 			cause_source_value varchar(50) NULL,
 			cause_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.NOTE (
 			note_id integer NOT NULL,
@@ -235,7 +223,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE (
 			note_source_value varchar(50) NULL,
 			note_event_id integer NULL,
 			note_event_field_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
 			note_nlp_id integer NOT NULL,
@@ -252,7 +239,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
 			term_exists varchar(1) NULL,
 			term_temporal varchar(50) NULL,
 			term_modifiers varchar(2000) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
 			specimen_id integer NOT NULL,
@@ -270,7 +256,6 @@ CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
 			unit_source_value varchar(50) NULL,
 			anatomic_site_source_value varchar(50) NULL,
 			disease_status_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
 			domain_concept_id_1 integer NOT NULL,
@@ -278,7 +263,6 @@ CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
 			domain_concept_id_2 integer NOT NULL,
 			fact_id_2 integer NOT NULL,
 			relationship_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.LOCATION (
 			location_id integer NOT NULL,
@@ -293,7 +277,6 @@ CREATE TABLE @cdmDatabaseSchema.LOCATION (
 			country_source_value varchar(80) NULL,
 			latitude NUMERIC NULL,
 			longitude NUMERIC NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
 			care_site_id integer NOT NULL,
@@ -302,7 +285,6 @@ CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
 			location_id integer NULL,
 			care_site_source_value varchar(50) NULL,
 			place_of_service_source_value varchar(50) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.PROVIDER (
 			provider_id integer NOT NULL,
@@ -318,7 +300,6 @@ CREATE TABLE @cdmDatabaseSchema.PROVIDER (
 			specialty_source_concept_id integer NULL,
 			gender_source_value varchar(50) NULL,
 			gender_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
 			payer_plan_period_id integer NOT NULL,
@@ -338,7 +319,6 @@ CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
 			stop_reason_concept_id integer NULL,
 			stop_reason_source_value varchar(50) NULL,
 			stop_reason_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COST (
 			cost_id integer NOT NULL,
@@ -363,7 +343,6 @@ CREATE TABLE @cdmDatabaseSchema.COST (
 			revenue_code_source_value varchar(50) NULL,
 			drg_concept_id integer NULL,
 			drg_source_value varchar(3) NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
 			drug_era_id integer NOT NULL,
@@ -373,7 +352,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
 			drug_era_end_date date NOT NULL,
 			drug_exposure_count integer NULL,
 			gap_days integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
 			dose_era_id integer NOT NULL,
@@ -383,7 +361,6 @@ CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
 			dose_value NUMERIC NOT NULL,
 			dose_era_start_date date NOT NULL,
 			dose_era_end_date date NOT NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
 			condition_era_id integer NOT NULL,
@@ -392,7 +369,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
 			condition_era_start_date date NOT NULL,
 			condition_era_end_date date NOT NULL,
 			condition_occurrence_count integer NULL );
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.EPISODE (
 			episode_id integer NOT NULL,
@@ -408,13 +384,11 @@ CREATE TABLE @cdmDatabaseSchema.EPISODE (
 			episode_type_concept_id integer NOT NULL,
 			episode_source_value varchar(50) NULL,
 			episode_source_concept_id integer NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT (
 			episode_id integer NOT NULL,
 			event_id integer NOT NULL,
 			episode_event_field_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.METADATA (
 			metadata_id integer NOT NULL,
@@ -426,7 +400,6 @@ CREATE TABLE @cdmDatabaseSchema.METADATA (
 			value_as_number NUMERIC NULL,
 			metadata_date date NULL,
 			metadata_datetime TIMESTAMP NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
 			cdm_source_name varchar(255) NOT NULL,
@@ -440,7 +413,6 @@ CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
 			cdm_version varchar(10) NULL,
 			cdm_version_concept_id integer NOT NULL,
 			vocabulary_version varchar(20) NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT (
 			concept_id integer NOT NULL,
@@ -453,7 +425,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
 			vocabulary_id varchar(20) NOT NULL,
@@ -461,19 +432,16 @@ CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
 			vocabulary_reference varchar(255) NULL,
 			vocabulary_version varchar(255) NULL,
 			vocabulary_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DOMAIN (
 			domain_id varchar(20) NOT NULL,
 			domain_name varchar(255) NOT NULL,
 			domain_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS (
 			concept_class_id varchar(20) NOT NULL,
 			concept_class_name varchar(255) NOT NULL,
 			concept_class_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
 			concept_id_1 integer NOT NULL,
@@ -482,7 +450,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
 			relationship_id varchar(20) NOT NULL,
@@ -491,20 +458,17 @@ CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
 			defines_ancestry varchar(1) NOT NULL,
 			reverse_relationship_id varchar(20) NOT NULL,
 			relationship_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM (
 			concept_id integer NOT NULL,
 			concept_synonym_name varchar(1000) NOT NULL,
 			language_concept_id integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR (
 			ancestor_concept_id integer NOT NULL,
 			descendant_concept_id integer NOT NULL,
 			min_levels_of_separation integer NOT NULL,
 			max_levels_of_separation integer NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
 			source_code varchar(50) NOT NULL,
@@ -516,7 +480,6 @@ CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
 			drug_concept_id integer NOT NULL,
@@ -531,14 +494,12 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
 			valid_start_date date NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT (
 			cohort_definition_id integer NOT NULL,
 			subject_id integer NOT NULL,
 			cohort_start_date date NOT NULL,
 			cohort_end_date date NOT NULL );
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION (
 			cohort_definition_id integer NOT NULL,
diff --git a/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_indices.sql b/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_indices.sql
index 8e6378fd..efc91518 100644
--- a/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_indices.sql
+++ b/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_indices.sql
@@ -1,190 +1,130 @@
 /*postgresql OMOP CDM Indices
-
   There are no unique indices created because it is assumed that the primary key constraints have been run prior to
   implementing indices.
 */
-
-
 /************************
-
 Standardized clinical data
-
 ************************/
-
 CREATE INDEX idx_person_id  ON @cdmDatabaseSchema.person  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.person  USING idx_person_id ;
 CREATE INDEX idx_gender ON @cdmDatabaseSchema.person (gender_concept_id ASC);
-
 CREATE INDEX idx_observation_period_id_1  ON @cdmDatabaseSchema.observation_period  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.observation_period  USING idx_observation_period_id_1 ;
-
 CREATE INDEX idx_visit_person_id_1  ON @cdmDatabaseSchema.visit_occurrence  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.visit_occurrence  USING idx_visit_person_id_1 ;
 CREATE INDEX idx_visit_concept_id_1 ON @cdmDatabaseSchema.visit_occurrence (visit_concept_id ASC);
-
 CREATE INDEX idx_visit_det_person_id_1  ON @cdmDatabaseSchema.visit_detail  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.visit_detail  USING idx_visit_det_person_id_1 ;
 CREATE INDEX idx_visit_det_concept_id_1 ON @cdmDatabaseSchema.visit_detail (visit_detail_concept_id ASC);
 CREATE INDEX idx_visit_det_occ_id ON @cdmDatabaseSchema.visit_detail (visit_occurrence_id ASC);
-
 CREATE INDEX idx_condition_person_id_1  ON @cdmDatabaseSchema.condition_occurrence  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.condition_occurrence  USING idx_condition_person_id_1 ;
 CREATE INDEX idx_condition_concept_id_1 ON @cdmDatabaseSchema.condition_occurrence (condition_concept_id ASC);
 CREATE INDEX idx_condition_visit_id_1 ON @cdmDatabaseSchema.condition_occurrence (visit_occurrence_id ASC);
-
 CREATE INDEX idx_drug_person_id_1  ON @cdmDatabaseSchema.drug_exposure  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.drug_exposure  USING idx_drug_person_id_1 ;
 CREATE INDEX idx_drug_concept_id_1 ON @cdmDatabaseSchema.drug_exposure (drug_concept_id ASC);
 CREATE INDEX idx_drug_visit_id_1 ON @cdmDatabaseSchema.drug_exposure (visit_occurrence_id ASC);
-
 CREATE INDEX idx_procedure_person_id_1  ON @cdmDatabaseSchema.procedure_occurrence  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.procedure_occurrence  USING idx_procedure_person_id_1 ;
 CREATE INDEX idx_procedure_concept_id_1 ON @cdmDatabaseSchema.procedure_occurrence (procedure_concept_id ASC);
 CREATE INDEX idx_procedure_visit_id_1 ON @cdmDatabaseSchema.procedure_occurrence (visit_occurrence_id ASC);
-
 CREATE INDEX idx_device_person_id_1  ON @cdmDatabaseSchema.device_exposure  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.device_exposure  USING idx_device_person_id_1 ;
 CREATE INDEX idx_device_concept_id_1 ON @cdmDatabaseSchema.device_exposure (device_concept_id ASC);
 CREATE INDEX idx_device_visit_id_1 ON @cdmDatabaseSchema.device_exposure (visit_occurrence_id ASC);
-
 CREATE INDEX idx_measurement_person_id_1  ON @cdmDatabaseSchema.measurement  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.measurement  USING idx_measurement_person_id_1 ;
 CREATE INDEX idx_measurement_concept_id_1 ON @cdmDatabaseSchema.measurement (measurement_concept_id ASC);
 CREATE INDEX idx_measurement_visit_id_1 ON @cdmDatabaseSchema.measurement (visit_occurrence_id ASC);
-
 CREATE INDEX idx_observation_person_id_1  ON @cdmDatabaseSchema.observation  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.observation  USING idx_observation_person_id_1 ;
 CREATE INDEX idx_observation_concept_id_1 ON @cdmDatabaseSchema.observation (observation_concept_id ASC);
 CREATE INDEX idx_observation_visit_id_1 ON @cdmDatabaseSchema.observation (visit_occurrence_id ASC);
-
 CREATE INDEX idx_death_person_id_1  ON @cdmDatabaseSchema.death  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.death  USING idx_death_person_id_1 ;
-
 CREATE INDEX idx_note_person_id_1  ON @cdmDatabaseSchema.note  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.note  USING idx_note_person_id_1 ;
 CREATE INDEX idx_note_concept_id_1 ON @cdmDatabaseSchema.note (note_type_concept_id ASC);
 CREATE INDEX idx_note_visit_id_1 ON @cdmDatabaseSchema.note (visit_occurrence_id ASC);
-
 CREATE INDEX idx_note_nlp_note_id_1  ON @cdmDatabaseSchema.note_nlp  (note_id ASC);
 CLUSTER @cdmDatabaseSchema.note_nlp  USING idx_note_nlp_note_id_1 ;
 CREATE INDEX idx_note_nlp_concept_id_1 ON @cdmDatabaseSchema.note_nlp (note_nlp_concept_id ASC);
-
 CREATE INDEX idx_specimen_person_id_1  ON @cdmDatabaseSchema.specimen  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.specimen  USING idx_specimen_person_id_1 ;
 CREATE INDEX idx_specimen_concept_id_1 ON @cdmDatabaseSchema.specimen (specimen_concept_id ASC);
-
 CREATE INDEX idx_fact_relationship_id1 ON @cdmDatabaseSchema.fact_relationship (domain_concept_id_1 ASC);
 CREATE INDEX idx_fact_relationship_id2 ON @cdmDatabaseSchema.fact_relationship (domain_concept_id_2 ASC);
 CREATE INDEX idx_fact_relationship_id3 ON @cdmDatabaseSchema.fact_relationship (relationship_concept_id ASC);
-
 /************************
-
 Standardized health system data
-
 ************************/
-
 CREATE INDEX idx_location_id_1  ON @cdmDatabaseSchema.location  (location_id ASC);
 CLUSTER @cdmDatabaseSchema.location  USING idx_location_id_1 ;
-
 CREATE INDEX idx_care_site_id_1  ON @cdmDatabaseSchema.care_site  (care_site_id ASC);
 CLUSTER @cdmDatabaseSchema.care_site  USING idx_care_site_id_1 ;
-
 CREATE INDEX idx_provider_id_1  ON @cdmDatabaseSchema.provider  (provider_id ASC);
 CLUSTER @cdmDatabaseSchema.provider  USING idx_provider_id_1 ;
-
 /************************
-
 Standardized health economics
-
 ************************/
-
 CREATE INDEX idx_period_person_id_1  ON @cdmDatabaseSchema.payer_plan_period  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.payer_plan_period  USING idx_period_person_id_1 ;
-
 CREATE INDEX idx_cost_event_id  ON @cdmDatabaseSchema.cost (cost_event_id ASC);
-
 /************************
-
 Standardized derived elements
-
 ************************/
-
 CREATE INDEX idx_drug_era_person_id_1  ON @cdmDatabaseSchema.drug_era  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.drug_era  USING idx_drug_era_person_id_1 ;
 CREATE INDEX idx_drug_era_concept_id_1 ON @cdmDatabaseSchema.drug_era (drug_concept_id ASC);
-
 CREATE INDEX idx_dose_era_person_id_1  ON @cdmDatabaseSchema.dose_era  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.dose_era  USING idx_dose_era_person_id_1 ;
 CREATE INDEX idx_dose_era_concept_id_1 ON @cdmDatabaseSchema.dose_era (drug_concept_id ASC);
-
 CREATE INDEX idx_condition_era_person_id_1  ON @cdmDatabaseSchema.condition_era  (person_id ASC);
 CLUSTER @cdmDatabaseSchema.condition_era  USING idx_condition_era_person_id_1 ;
 CREATE INDEX idx_condition_era_concept_id_1 ON @cdmDatabaseSchema.condition_era (condition_concept_id ASC);
-
 /**************************
-
 Standardized meta-data
-
 ***************************/
-
 CREATE INDEX idx_metadata_concept_id_1  ON @cdmDatabaseSchema.metadata  (metadata_concept_id ASC);
 CLUSTER @cdmDatabaseSchema.metadata  USING idx_metadata_concept_id_1 ;
-
 /**************************
-
 Standardized vocabularies
-
 ***************************/
-
 CREATE INDEX idx_concept_concept_id  ON @cdmDatabaseSchema.concept  (concept_id ASC);
 CLUSTER @cdmDatabaseSchema.concept  USING idx_concept_concept_id ;
 CREATE INDEX idx_concept_code ON @cdmDatabaseSchema.concept (concept_code ASC);
 CREATE INDEX idx_concept_vocabluary_id ON @cdmDatabaseSchema.concept (vocabulary_id ASC);
 CREATE INDEX idx_concept_domain_id ON @cdmDatabaseSchema.concept (domain_id ASC);
 CREATE INDEX idx_concept_class_id ON @cdmDatabaseSchema.concept (concept_class_id ASC);
-
 CREATE INDEX idx_vocabulary_vocabulary_id  ON @cdmDatabaseSchema.vocabulary  (vocabulary_id ASC);
 CLUSTER @cdmDatabaseSchema.vocabulary  USING idx_vocabulary_vocabulary_id ;
-
 CREATE INDEX idx_domain_domain_id  ON @cdmDatabaseSchema.domain  (domain_id ASC);
 CLUSTER @cdmDatabaseSchema.domain  USING idx_domain_domain_id ;
-
 CREATE INDEX idx_concept_class_class_id  ON @cdmDatabaseSchema.concept_class  (concept_class_id ASC);
 CLUSTER @cdmDatabaseSchema.concept_class  USING idx_concept_class_class_id ;
-
 CREATE INDEX idx_concept_relationship_id_1  ON @cdmDatabaseSchema.concept_relationship  (concept_id_1 ASC);
 CLUSTER @cdmDatabaseSchema.concept_relationship  USING idx_concept_relationship_id_1 ;
 CREATE INDEX idx_concept_relationship_id_2 ON @cdmDatabaseSchema.concept_relationship (concept_id_2 ASC);
 CREATE INDEX idx_concept_relationship_id_3 ON @cdmDatabaseSchema.concept_relationship (relationship_id ASC);
-
 CREATE INDEX idx_relationship_rel_id  ON @cdmDatabaseSchema.relationship  (relationship_id ASC);
 CLUSTER @cdmDatabaseSchema.relationship  USING idx_relationship_rel_id ;
-
 CREATE INDEX idx_concept_synonym_id  ON @cdmDatabaseSchema.concept_synonym  (concept_id ASC);
 CLUSTER @cdmDatabaseSchema.concept_synonym  USING idx_concept_synonym_id ;
-
 CREATE INDEX idx_concept_ancestor_id_1  ON @cdmDatabaseSchema.concept_ancestor  (ancestor_concept_id ASC);
 CLUSTER @cdmDatabaseSchema.concept_ancestor  USING idx_concept_ancestor_id_1 ;
 CREATE INDEX idx_concept_ancestor_id_2 ON @cdmDatabaseSchema.concept_ancestor (descendant_concept_id ASC);
-
 CREATE INDEX idx_source_to_concept_map_3  ON @cdmDatabaseSchema.source_to_concept_map  (target_concept_id ASC);
 CLUSTER @cdmDatabaseSchema.source_to_concept_map  USING idx_source_to_concept_map_3 ;
 CREATE INDEX idx_source_to_concept_map_1 ON @cdmDatabaseSchema.source_to_concept_map (source_vocabulary_id ASC);
 CREATE INDEX idx_source_to_concept_map_2 ON @cdmDatabaseSchema.source_to_concept_map (target_vocabulary_id ASC);
 CREATE INDEX idx_source_to_concept_map_c ON @cdmDatabaseSchema.source_to_concept_map (source_code ASC);
-
 CREATE INDEX idx_drug_strength_id_1  ON @cdmDatabaseSchema.drug_strength  (drug_concept_id ASC);
 CLUSTER @cdmDatabaseSchema.drug_strength  USING idx_drug_strength_id_1 ;
 CREATE INDEX idx_drug_strength_id_2 ON @cdmDatabaseSchema.drug_strength (ingredient_concept_id ASC);
-
-
 --Additional v6.0 indices
-
 --CREATE CLUSTERED INDEX idx_survey_person_id_1 ON @cdmDatabaseSchema.survey_conduct (person_id ASC);
-
-
 --CREATE CLUSTERED INDEX idx_episode_person_id_1 ON @cdmDatabaseSchema.episode (person_id ASC);
 --CREATE INDEX idx_episode_concept_id_1 ON @cdmDatabaseSchema.episode (episode_concept_id ASC);
-
 --CREATE CLUSTERED INDEX idx_episode_event_id_1 ON @cdmDatabaseSchema.episode_event (episode_id ASC);
 --CREATE INDEX idx_ee_field_concept_id_1 ON @cdmDatabaseSchema.episode_event (event_field_concept_id ASC);
diff --git a/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_primary_keys.sql b/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_primary_keys.sql
index 063177c6..e51cf100 100644
--- a/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_primary_keys.sql
+++ b/inst/ddl/5.4/postgresql/OMOPCDM_postgresql_5.4_primary_keys.sql
@@ -1,57 +1,29 @@
 --postgresql CDM Primary Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT xpk_PERSON PRIMARY KEY (person_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT xpk_OBSERVATION_PERIOD PRIMARY KEY (observation_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT xpk_VISIT_OCCURRENCE PRIMARY KEY (visit_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT xpk_VISIT_DETAIL PRIMARY KEY (visit_detail_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT xpk_CONDITION_OCCURRENCE PRIMARY KEY (condition_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT xpk_DRUG_EXPOSURE PRIMARY KEY (drug_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT xpk_PROCEDURE_OCCURRENCE PRIMARY KEY (procedure_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT xpk_DEVICE_EXPOSURE PRIMARY KEY (device_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT xpk_MEASUREMENT PRIMARY KEY (measurement_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT xpk_OBSERVATION PRIMARY KEY (observation_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT xpk_NOTE PRIMARY KEY (note_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT xpk_NOTE_NLP PRIMARY KEY (note_nlp_id);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT xpk_SPECIMEN PRIMARY KEY (specimen_id);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT xpk_LOCATION PRIMARY KEY (location_id);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT xpk_CARE_SITE PRIMARY KEY (care_site_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT xpk_PROVIDER PRIMARY KEY (provider_id);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT xpk_PAYER_PLAN_PERIOD PRIMARY KEY (payer_plan_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT xpk_COST PRIMARY KEY (cost_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT xpk_DRUG_ERA PRIMARY KEY (drug_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT xpk_DOSE_ERA PRIMARY KEY (dose_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT xpk_CONDITION_ERA PRIMARY KEY (condition_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT xpk_EPISODE PRIMARY KEY (episode_id);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT xpk_METADATA PRIMARY KEY (metadata_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT xpk_CONCEPT PRIMARY KEY (concept_id);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT xpk_VOCABULARY PRIMARY KEY (vocabulary_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT xpk_DOMAIN PRIMARY KEY (domain_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT xpk_CONCEPT_CLASS PRIMARY KEY (concept_class_id);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY (relationship_id);
diff --git a/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_constraints.sql b/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_constraints.sql
index f22043de..fa076961 100644
--- a/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_constraints.sql
+++ b/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_constraints.sql
@@ -1,353 +1,177 @@
 --redshift CDM Foreign Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_concept_id FOREIGN KEY (race_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_concept_id FOREIGN KEY (ethnicity_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_source_concept_id FOREIGN KEY (race_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_source_concept_id FOREIGN KEY (ethnicity_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_period_type_concept_id FOREIGN KEY (period_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_concept_id FOREIGN KEY (visit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_type_concept_id FOREIGN KEY (visit_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_source_concept_id FOREIGN KEY (visit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_preceding_visit_occurrence_id FOREIGN KEY (preceding_visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_concept_id FOREIGN KEY (visit_detail_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_type_concept_id FOREIGN KEY (visit_detail_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_source_concept_id FOREIGN KEY (visit_detail_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_preceding_visit_detail_id FOREIGN KEY (preceding_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_parent_visit_detail_id FOREIGN KEY (parent_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_type_concept_id FOREIGN KEY (condition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_status_concept_id FOREIGN KEY (condition_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_source_concept_id FOREIGN KEY (condition_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_type_concept_id FOREIGN KEY (drug_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_route_concept_id FOREIGN KEY (route_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_source_concept_id FOREIGN KEY (drug_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_concept_id FOREIGN KEY (procedure_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_type_concept_id FOREIGN KEY (procedure_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_modifier_concept_id FOREIGN KEY (modifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_source_concept_id FOREIGN KEY (procedure_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_concept_id FOREIGN KEY (device_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_type_concept_id FOREIGN KEY (device_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_source_concept_id FOREIGN KEY (device_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_concept_id FOREIGN KEY (measurement_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_type_concept_id FOREIGN KEY (measurement_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_operator_concept_id FOREIGN KEY (operator_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_source_concept_id FOREIGN KEY (measurement_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_meas_event_field_concept_id FOREIGN KEY (meas_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_concept_id FOREIGN KEY (observation_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_type_concept_id FOREIGN KEY (observation_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_qualifier_concept_id FOREIGN KEY (qualifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_source_concept_id FOREIGN KEY (observation_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_obs_event_field_concept_id FOREIGN KEY (obs_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_death_type_concept_id FOREIGN KEY (death_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_concept_id FOREIGN KEY (cause_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_source_concept_id FOREIGN KEY (cause_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_type_concept_id FOREIGN KEY (note_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_class_concept_id FOREIGN KEY (note_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_encoding_concept_id FOREIGN KEY (encoding_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_event_field_concept_id FOREIGN KEY (note_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_section_concept_id FOREIGN KEY (section_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_concept_id FOREIGN KEY (note_nlp_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_source_concept_id FOREIGN KEY (note_nlp_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_concept_id FOREIGN KEY (specimen_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_type_concept_id FOREIGN KEY (specimen_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_anatomic_site_concept_id FOREIGN KEY (anatomic_site_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_disease_status_concept_id FOREIGN KEY (disease_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_1 FOREIGN KEY (domain_concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_2 FOREIGN KEY (domain_concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT fpk_LOCATION_country_concept_id FOREIGN KEY (country_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_place_of_service_concept_id FOREIGN KEY (place_of_service_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_concept_id FOREIGN KEY (specialty_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_source_concept_id FOREIGN KEY (specialty_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_concept_id FOREIGN KEY (payer_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_source_concept_id FOREIGN KEY (payer_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_concept_id FOREIGN KEY (plan_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_source_concept_id FOREIGN KEY (plan_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_concept_id FOREIGN KEY (sponsor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_source_concept_id FOREIGN KEY (sponsor_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_concept_id FOREIGN KEY (stop_reason_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_source_concept_id FOREIGN KEY (stop_reason_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_domain_id FOREIGN KEY (cost_domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_type_concept_id FOREIGN KEY (cost_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_currency_concept_id FOREIGN KEY (currency_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_revenue_code_concept_id FOREIGN KEY (revenue_code_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_drg_concept_id FOREIGN KEY (drg_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_concept_id FOREIGN KEY (episode_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_object_concept_id FOREIGN KEY (episode_object_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_type_concept_id FOREIGN KEY (episode_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_source_concept_id FOREIGN KEY (episode_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_id FOREIGN KEY (episode_id) REFERENCES @cdmDatabaseSchema.EPISODE (EPISODE_ID);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_event_field_concept_id FOREIGN KEY (episode_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_concept_id FOREIGN KEY (metadata_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_type_concept_id FOREIGN KEY (metadata_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CDM_SOURCE ADD CONSTRAINT fpk_CDM_SOURCE_cdm_version_concept_id FOREIGN KEY (cdm_version_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_domain_id FOREIGN KEY (domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_vocabulary_id FOREIGN KEY (vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_concept_class_id FOREIGN KEY (concept_class_id) REFERENCES @cdmDatabaseSchema.CONCEPT_CLASS (CONCEPT_CLASS_ID);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT fpk_VOCABULARY_vocabulary_concept_id FOREIGN KEY (vocabulary_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT fpk_DOMAIN_domain_concept_id FOREIGN KEY (domain_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT fpk_CONCEPT_CLASS_concept_class_concept_id FOREIGN KEY (concept_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_1 FOREIGN KEY (concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_2 FOREIGN KEY (concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_relationship_id FOREIGN KEY (relationship_id) REFERENCES @cdmDatabaseSchema.RELATIONSHIP (RELATIONSHIP_ID);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT fpk_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_concept_id FOREIGN KEY (concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_ancestor_concept_id FOREIGN KEY (ancestor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_descendant_concept_id FOREIGN KEY (descendant_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_source_concept_id FOREIGN KEY (source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_concept_id FOREIGN KEY (target_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_vocabulary_id FOREIGN KEY (target_vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_ingredient_concept_id FOREIGN KEY (ingredient_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_amount_unit_concept_id FOREIGN KEY (amount_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_numerator_unit_concept_id FOREIGN KEY (numerator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_denominator_unit_concept_id FOREIGN KEY (denominator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_definition_type_concept_id FOREIGN KEY (definition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_subject_concept_id FOREIGN KEY (subject_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
diff --git a/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_ddl.sql b/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_ddl.sql
index 0a564712..227cf3d5 100644
--- a/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_ddl.sql
+++ b/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_ddl.sql
@@ -1,5 +1,4 @@
 --redshift CDM DDL Specification for OMOP Common Data Model 5.4
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PERSON  ( person_id integer NOT NULL,
 			gender_concept_id integer NOT NULL,
@@ -20,7 +19,6 @@ CREATE TABLE @cdmDatabaseSchema.PERSON  ( person_id integer NOT NULL,
 			ethnicity_source_value varchar(50) NULL,
 			ethnicity_source_concept_id integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD  (observation_period_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -28,7 +26,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD  (observation_period_id integ
 			observation_period_end_date date NOT NULL,
 			period_type_concept_id integer NOT NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE  (visit_occurrence_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -48,7 +45,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE  (visit_occurrence_id integer N
 			discharged_to_source_value varchar(50) NULL,
 			preceding_visit_occurrence_id integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL  (visit_detail_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -70,7 +66,6 @@ CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL  (visit_detail_id integer NOT NULL,
 			parent_visit_detail_id integer NULL,
 			visit_occurrence_id integer NOT NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE  (condition_occurrence_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -89,7 +84,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE  (condition_occurrence_id i
 			condition_source_concept_id integer NULL,
 			condition_status_source_value varchar(50) NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE  (drug_exposure_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -115,7 +109,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE  (drug_exposure_id integer NOT NUL
 			route_source_value varchar(50) NULL,
 			dose_unit_source_value varchar(50) NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE  (procedure_occurrence_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -134,7 +127,6 @@ CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE  (procedure_occurrence_id i
 			procedure_source_concept_id integer NULL,
 			modifier_source_value varchar(50) NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE  (device_exposure_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -156,7 +148,6 @@ CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE  (device_exposure_id integer NOT
 			unit_source_value varchar(50) NULL,
 			unit_source_concept_id integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.MEASUREMENT  (measurement_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -182,7 +173,6 @@ CREATE TABLE @cdmDatabaseSchema.MEASUREMENT  (measurement_id integer NOT NULL,
 			measurement_event_id integer NULL,
 			meas_event_field_concept_id integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION  (observation_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -206,7 +196,6 @@ CREATE TABLE @cdmDatabaseSchema.OBSERVATION  (observation_id integer NOT NULL,
 			observation_event_id integer NULL,
 			obs_event_field_concept_id integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEATH  ( person_id integer NOT NULL,
 			death_date date NOT NULL,
@@ -216,7 +205,6 @@ CREATE TABLE @cdmDatabaseSchema.DEATH  ( person_id integer NOT NULL,
 			cause_source_value varchar(50) NULL,
 			cause_source_concept_id integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.NOTE  (note_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -235,7 +223,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE  (note_id integer NOT NULL,
 			note_event_id integer NULL,
 			note_event_field_concept_id integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.NOTE_NLP  (note_nlp_id integer NOT NULL,
 			note_id integer NOT NULL,
@@ -252,7 +239,6 @@ CREATE TABLE @cdmDatabaseSchema.NOTE_NLP  (note_nlp_id integer NOT NULL,
 			term_temporal varchar(50) NULL,
 			term_modifiers varchar(2000) NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.SPECIMEN  (specimen_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -270,7 +256,6 @@ CREATE TABLE @cdmDatabaseSchema.SPECIMEN  (specimen_id integer NOT NULL,
 			anatomic_site_source_value varchar(50) NULL,
 			disease_status_source_value varchar(50) NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP  (domain_concept_id_1 integer NOT NULL,
 			fact_id_1 integer NOT NULL,
@@ -278,7 +263,6 @@ CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP  (domain_concept_id_1 integer
 			fact_id_2 integer NOT NULL,
 			relationship_concept_id integer NOT NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.LOCATION  (location_id integer NOT NULL,
 			address_1 varchar(50) NULL,
@@ -293,7 +277,6 @@ CREATE TABLE @cdmDatabaseSchema.LOCATION  (location_id integer NOT NULL,
 			latitude float NULL,
 			longitude float NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CARE_SITE  (care_site_id integer NOT NULL,
 			care_site_name varchar(255) NULL,
@@ -302,7 +285,6 @@ CREATE TABLE @cdmDatabaseSchema.CARE_SITE  (care_site_id integer NOT NULL,
 			care_site_source_value varchar(50) NULL,
 			place_of_service_source_value varchar(50) NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.PROVIDER  (provider_id integer NOT NULL,
 			provider_name varchar(255) NULL,
@@ -318,7 +300,6 @@ CREATE TABLE @cdmDatabaseSchema.PROVIDER  (provider_id integer NOT NULL,
 			gender_source_value varchar(50) NULL,
 			gender_source_concept_id integer NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD  (payer_plan_period_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -338,7 +319,6 @@ CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD  (payer_plan_period_id integer
 			stop_reason_source_value varchar(50) NULL,
 			stop_reason_source_concept_id integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COST  (cost_id integer NOT NULL,
 			cost_event_id integer NOT NULL,
@@ -363,7 +343,6 @@ CREATE TABLE @cdmDatabaseSchema.COST  (cost_id integer NOT NULL,
 			drg_concept_id integer NULL,
 			drg_source_value varchar(3) NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_ERA  (drug_era_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -373,7 +352,6 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_ERA  (drug_era_id integer NOT NULL,
 			drug_exposure_count integer NULL,
 			gap_days integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DOSE_ERA  (dose_era_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -383,7 +361,6 @@ CREATE TABLE @cdmDatabaseSchema.DOSE_ERA  (dose_era_id integer NOT NULL,
 			dose_era_start_date date NOT NULL,
 			dose_era_end_date date NOT NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA  (condition_era_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -392,7 +369,6 @@ CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA  (condition_era_id integer NOT NUL
 			condition_era_end_date date NOT NULL,
 			condition_occurrence_count integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.EPISODE  (episode_id integer NOT NULL,
 			 person_id integer NOT NULL,
@@ -408,13 +384,11 @@ CREATE TABLE @cdmDatabaseSchema.EPISODE  (episode_id integer NOT NULL,
 			episode_source_value varchar(50) NULL,
 			episode_source_concept_id integer NULL )
 DISTKEY(person_id);
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT  (episode_id integer NOT NULL,
 			event_id integer NOT NULL,
 			episode_event_field_concept_id integer NOT NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.METADATA  (metadata_id integer NOT NULL,
 			metadata_concept_id integer NOT NULL,
@@ -426,7 +400,6 @@ CREATE TABLE @cdmDatabaseSchema.METADATA  (metadata_id integer NOT NULL,
 			metadata_date date NULL,
 			metadata_datetime TIMESTAMP NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE  (cdm_source_name varchar(255) NOT NULL,
 			cdm_source_abbreviation varchar(25) NOT NULL,
@@ -440,7 +413,6 @@ CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE  (cdm_source_name varchar(255) NOT NU
 			cdm_version_concept_id integer NOT NULL,
 			vocabulary_version varchar(20) NOT NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT  (concept_id integer NOT NULL,
 			concept_name varchar(255) NOT NULL,
@@ -453,7 +425,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT  (concept_id integer NOT NULL,
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.VOCABULARY  (vocabulary_id varchar(20) NOT NULL,
 			vocabulary_name varchar(255) NOT NULL,
@@ -461,19 +432,16 @@ CREATE TABLE @cdmDatabaseSchema.VOCABULARY  (vocabulary_id varchar(20) NOT NULL,
 			vocabulary_version varchar(255) NULL,
 			vocabulary_concept_id integer NOT NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DOMAIN  (domain_id varchar(20) NOT NULL,
 			domain_name varchar(255) NOT NULL,
 			domain_concept_id integer NOT NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS  (concept_class_id varchar(20) NOT NULL,
 			concept_class_name varchar(255) NOT NULL,
 			concept_class_concept_id integer NOT NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP  (concept_id_1 integer NOT NULL,
 			concept_id_2 integer NOT NULL,
@@ -482,7 +450,6 @@ CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP  (concept_id_1 integer NOT
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP  (relationship_id varchar(20) NOT NULL,
 			relationship_name varchar(255) NOT NULL,
@@ -491,20 +458,17 @@ CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP  (relationship_id varchar(20) NOT N
 			reverse_relationship_id varchar(20) NOT NULL,
 			relationship_concept_id integer NOT NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM  (concept_id integer NOT NULL,
 			concept_synonym_name varchar(1000) NOT NULL,
 			language_concept_id integer NOT NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR  (ancestor_concept_id integer NOT NULL,
 			descendant_concept_id integer NOT NULL,
 			min_levels_of_separation integer NOT NULL,
 			max_levels_of_separation integer NOT NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP  (source_code varchar(50) NOT NULL,
 			source_concept_id integer NOT NULL,
@@ -516,7 +480,6 @@ CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP  (source_code varchar(50)
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH  (drug_concept_id integer NOT NULL,
 			ingredient_concept_id integer NOT NULL,
@@ -531,14 +494,12 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH  (drug_concept_id integer NOT NULL
 			valid_end_date date NOT NULL,
 			invalid_reason varchar(1) NULL )
 DISTSTYLE ALL;
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT  (cohort_definition_id integer NOT NULL,
 			 subject_id integer NOT NULL,
 			cohort_start_date date NOT NULL,
 			cohort_end_date date NOT NULL )
 DISTKEY(subject_id);
-
 --HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION  (cohort_definition_id integer NOT NULL,
 			cohort_definition_name varchar(255) NOT NULL,
diff --git a/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_indices.sql b/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_indices.sql
index 52a1eec6..237f9767 100644
--- a/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_indices.sql
+++ b/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_indices.sql
@@ -1,158 +1,98 @@
 /*redshift OMOP CDM Indices
-
   There are no unique indices created because it is assumed that the primary key constraints have been run prior to
   implementing indices.
 */
-
-
 /************************
-
 Standardized clinical data
-
 ************************/
-
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 /************************
-
 Standardized health system data
-
 ************************/
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 /************************
-
 Standardized health economics
-
 ************************/
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 /************************
-
 Standardized derived elements
-
 ************************/
-
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 /**************************
-
 Standardized meta-data
-
 ***************************/
-
 -- redshift does not support indexes
-
 /**************************
-
 Standardized vocabularies
-
 ***************************/
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
 -- redshift does not support indexes
-
 -- redshift does not support indexes
 -- redshift does not support indexes
-
-
 --Additional v6.0 indices
-
 --CREATE CLUSTERED INDEX idx_survey_person_id_1 ON @cdmDatabaseSchema.survey_conduct (person_id ASC);
-
-
 --CREATE CLUSTERED INDEX idx_episode_person_id_1 ON @cdmDatabaseSchema.episode (person_id ASC);
 --CREATE INDEX idx_episode_concept_id_1 ON @cdmDatabaseSchema.episode (episode_concept_id ASC);
-
 --CREATE CLUSTERED INDEX idx_episode_event_id_1 ON @cdmDatabaseSchema.episode_event (episode_id ASC);
 --CREATE INDEX idx_ee_field_concept_id_1 ON @cdmDatabaseSchema.episode_event (event_field_concept_id ASC);
diff --git a/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_primary_keys.sql b/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_primary_keys.sql
index 7243a25d..948638c8 100644
--- a/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_primary_keys.sql
+++ b/inst/ddl/5.4/redshift/OMOPCDM_redshift_5.4_primary_keys.sql
@@ -1,57 +1,29 @@
 --redshift CDM Primary Key Constraints for OMOP Common Data Model 5.4
-
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT xpk_PERSON PRIMARY KEY (person_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT xpk_OBSERVATION_PERIOD PRIMARY KEY (observation_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT xpk_VISIT_OCCURRENCE PRIMARY KEY (visit_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT xpk_VISIT_DETAIL PRIMARY KEY (visit_detail_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT xpk_CONDITION_OCCURRENCE PRIMARY KEY (condition_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT xpk_DRUG_EXPOSURE PRIMARY KEY (drug_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT xpk_PROCEDURE_OCCURRENCE PRIMARY KEY (procedure_occurrence_id);
-
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT xpk_DEVICE_EXPOSURE PRIMARY KEY (device_exposure_id);
-
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT xpk_MEASUREMENT PRIMARY KEY (measurement_id);
-
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT xpk_OBSERVATION PRIMARY KEY (observation_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT xpk_NOTE PRIMARY KEY (note_id);
-
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT xpk_NOTE_NLP PRIMARY KEY (note_nlp_id);
-
 ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT xpk_SPECIMEN PRIMARY KEY (specimen_id);
-
 ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT xpk_LOCATION PRIMARY KEY (location_id);
-
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT xpk_CARE_SITE PRIMARY KEY (care_site_id);
-
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT xpk_PROVIDER PRIMARY KEY (provider_id);
-
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT xpk_PAYER_PLAN_PERIOD PRIMARY KEY (payer_plan_period_id);
-
 ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT xpk_COST PRIMARY KEY (cost_id);
-
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT xpk_DRUG_ERA PRIMARY KEY (drug_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT xpk_DOSE_ERA PRIMARY KEY (dose_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT xpk_CONDITION_ERA PRIMARY KEY (condition_era_id);
-
 ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT xpk_EPISODE PRIMARY KEY (episode_id);
-
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT xpk_METADATA PRIMARY KEY (metadata_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT xpk_CONCEPT PRIMARY KEY (concept_id);
-
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT xpk_VOCABULARY PRIMARY KEY (vocabulary_id);
-
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT xpk_DOMAIN PRIMARY KEY (domain_id);
-
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT xpk_CONCEPT_CLASS PRIMARY KEY (concept_class_id);
-
 ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY (relationship_id);
diff --git a/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_constraints.sql b/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_constraints.sql
index 6f63fb9d..9e72273d 100644
--- a/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_constraints.sql
+++ b/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_constraints.sql
@@ -1,7 +1,8 @@
+--snowflake CDM Foreign Key Constraints for OMOP Common Data Model 5.4
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_concept_id FOREIGN KEY (race_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_concept_id FOREIGN KEY (ethnicity_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_location_id FOREIGN KEY (location_id) REFERENCES LOCATION (LOCATION_ID);
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
@@ -15,8 +16,8 @@ ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRE
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_source_concept_id FOREIGN KEY (visit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_admitting_source_concept_id FOREIGN KEY (admitting_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_discharge_to_concept_id FOREIGN KEY (discharge_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_preceding_visit_occurrence_id FOREIGN KEY (preceding_visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_concept_id FOREIGN KEY (visit_detail_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
@@ -24,10 +25,10 @@ ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visi
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_source_concept_id FOREIGN KEY (visit_detail_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_admitting_source_concept_id FOREIGN KEY (admitting_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_discharge_to_concept_id FOREIGN KEY (discharge_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_preceding_visit_detail_id FOREIGN KEY (preceding_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
-ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_parent_id FOREIGN KEY (visit_detail_parent_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_parent_visit_detail_id FOREIGN KEY (parent_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
 ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
@@ -49,6 +50,10 @@ ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_concept_id FOREIGN KEY (procedure_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_type_concept_id FOREIGN KEY (procedure_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_modifier_concept_id FOREIGN KEY (modifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_source_concept_id FOREIGN KEY (procedure_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_concept_id FOREIGN KEY (device_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_type_concept_id FOREIGN KEY (device_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
@@ -56,6 +61,8 @@ ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSUR
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
 ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_source_concept_id FOREIGN KEY (device_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_concept_id FOREIGN KEY (measurement_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_type_concept_id FOREIGN KEY (measurement_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
@@ -66,6 +73,8 @@ ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_provid
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
 ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_source_concept_id FOREIGN KEY (measurement_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_meas_event_field_concept_id FOREIGN KEY (meas_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_concept_id FOREIGN KEY (observation_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_type_concept_id FOREIGN KEY (observation_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
@@ -76,6 +85,7 @@ ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_provid
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_source_concept_id FOREIGN KEY (observation_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_obs_event_field_concept_id FOREIGN KEY (obs_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_death_type_concept_id FOREIGN KEY (death_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_concept_id FOREIGN KEY (cause_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
@@ -88,6 +98,7 @@ ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_language_concept_id
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
 ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_event_field_concept_id FOREIGN KEY (note_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_section_concept_id FOREIGN KEY (section_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_concept_id FOREIGN KEY (note_nlp_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_source_concept_id FOREIGN KEY (note_nlp_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
@@ -100,14 +111,14 @@ ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_disease_stat
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_1 FOREIGN KEY (domain_concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_2 FOREIGN KEY (domain_concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT fpk_LOCATION_country_concept_id FOREIGN KEY (country_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_place_of_service_concept_id FOREIGN KEY (place_of_service_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_location_id FOREIGN KEY (location_id) REFERENCES LOCATION (LOCATION_ID);
+ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_concept_id FOREIGN KEY (specialty_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_source_concept_id FOREIGN KEY (specialty_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_plan_period_id FOREIGN KEY (payer_plan_period_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_concept_id FOREIGN KEY (payer_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_source_concept_id FOREIGN KEY (payer_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
@@ -127,10 +138,19 @@ ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_drug_concept
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_concept_id FOREIGN KEY (episode_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_object_concept_id FOREIGN KEY (episode_object_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_type_concept_id FOREIGN KEY (episode_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_source_concept_id FOREIGN KEY (episode_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_id FOREIGN KEY (episode_id) REFERENCES @cdmDatabaseSchema.EPISODE (EPISODE_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_event_field_concept_id FOREIGN KEY (episode_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_concept_id FOREIGN KEY (metadata_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_type_concept_id FOREIGN KEY (metadata_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CDM_SOURCE ADD CONSTRAINT fpk_CDM_SOURCE_cdm_version_concept_id FOREIGN KEY (cdm_version_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_domain_id FOREIGN KEY (domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_vocabulary_id FOREIGN KEY (vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_concept_class_id FOREIGN KEY (concept_class_id) REFERENCES @cdmDatabaseSchema.CONCEPT_CLASS (CONCEPT_CLASS_ID);
@@ -155,4 +175,3 @@ ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_nu
 ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_denominator_unit_concept_id FOREIGN KEY (denominator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_definition_type_concept_id FOREIGN KEY (definition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
 ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_subject_concept_id FOREIGN KEY (subject_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
-ALTER TABLE @cdmDatabaseSchema.ATTRIBUTE_DEFINITION ADD CONSTRAINT fpk_ATTRIBUTE_DEFINITION_attribute_type_concept_id FOREIGN KEY (attribute_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
\ No newline at end of file
diff --git a/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_ddl.sql b/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_ddl.sql
index 8b191b48..0dc66319 100644
--- a/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_ddl.sql
+++ b/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_ddl.sql
@@ -1,481 +1,511 @@
---USE DATABASE snowflake54;
-
---CREATE OR REPLACE SCHEMA cdm54;
-
 --snowflake CDM DDL Specification for OMOP Common Data Model 5.4
-
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PERSON (
-                        person_id integer NOT NULL,
-                        gender_concept_id integer NOT NULL,
-                        year_of_birth integer NOT NULL,
-                        month_of_birth integer NULL,
-                        day_of_birth integer NULL,
-                        birth_datetime TIMESTAMP NULL,
-                        race_concept_id integer NOT NULL,
-                        ethnicity_concept_id integer NOT NULL,
-                        location_id integer NULL,
-                        provider_id integer NULL,
-                        care_site_id integer NULL,
-                        person_source_value varchar(50) NULL,
-                        gender_source_value varchar(50) NULL,
-                        gender_source_concept_id integer NULL,
-                        race_source_value varchar(50) NULL,
-                        race_source_concept_id integer NULL,
-                        ethnicity_source_value varchar(50) NULL,
-                        ethnicity_source_concept_id integer NULL );
-
+			person_id integer NOT NULL,
+			gender_concept_id integer NOT NULL,
+			year_of_birth integer NOT NULL,
+			month_of_birth integer NULL,
+			day_of_birth integer NULL,
+			birth_datetime TIMESTAMP NULL,
+			race_concept_id integer NOT NULL,
+			ethnicity_concept_id integer NOT NULL,
+			location_id integer NULL,
+			provider_id integer NULL,
+			care_site_id integer NULL,
+			person_source_value varchar(50) NULL,
+			gender_source_value varchar(50) NULL,
+			gender_source_concept_id integer NULL,
+			race_source_value varchar(50) NULL,
+			race_source_concept_id integer NULL,
+			ethnicity_source_value varchar(50) NULL,
+			ethnicity_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
-                                    observation_period_id integer NOT NULL,
-                                    person_id integer NOT NULL,
-                                    observation_period_start_date date NOT NULL,
-                                    observation_period_end_date date NOT NULL,
-                                    period_type_concept_id integer NOT NULL );
-
+			observation_period_id integer NOT NULL,
+			person_id integer NOT NULL,
+			observation_period_start_date date NOT NULL,
+			observation_period_end_date date NOT NULL,
+			period_type_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
-                                  visit_occurrence_id integer NOT NULL,
-                                  person_id integer NOT NULL,
-                                  visit_concept_id integer NOT NULL,
-                                  visit_start_date date NOT NULL,
-                                  visit_start_datetime TIMESTAMP NULL,
-                                  visit_end_date date NOT NULL,
-                                  visit_end_datetime TIMESTAMP NULL,
-                                  visit_type_concept_id Integer NOT NULL,
-                                  provider_id integer NULL,
-                                  care_site_id integer NULL,
-                                  visit_source_value varchar(50) NULL,
-                                  visit_source_concept_id integer NULL,
-                                  admitting_source_concept_id integer NULL,
-                                  admitting_source_value varchar(50) NULL,
-                                  discharge_to_concept_id integer NULL,
-                                  discharge_to_source_value varchar(50) NULL,
-                                  preceding_visit_occurrence_id integer NULL );
-
+			visit_occurrence_id integer NOT NULL,
+			person_id integer NOT NULL,
+			visit_concept_id integer NOT NULL,
+			visit_start_date date NOT NULL,
+			visit_start_datetime TIMESTAMP NULL,
+			visit_end_date date NOT NULL,
+			visit_end_datetime TIMESTAMP NULL,
+			visit_type_concept_id Integer NOT NULL,
+			provider_id integer NULL,
+			care_site_id integer NULL,
+			visit_source_value varchar(50) NULL,
+			visit_source_concept_id integer NULL,
+			admitted_from_concept_id integer NULL,
+			admitted_from_source_value varchar(50) NULL,
+			discharged_to_concept_id integer NULL,
+			discharged_to_source_value varchar(50) NULL,
+			preceding_visit_occurrence_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
-                              visit_detail_id integer NOT NULL,
-                              person_id integer NOT NULL,
-                              visit_detail_concept_id integer NOT NULL,
-                              visit_detail_start_date date NOT NULL,
-                              visit_detail_start_datetime TIMESTAMP NULL,
-                              visit_detail_end_date date NOT NULL,
-                              visit_detail_end_datetime TIMESTAMP NULL,
-                              visit_detail_type_concept_id integer NOT NULL,
-                              provider_id integer NULL,
-                              care_site_id integer NULL,
-                              visit_detail_source_value varchar(50) NULL,
-                              visit_detail_source_concept_id Integer NULL,
-                              admitting_source_value Varchar(50) NULL,
-                              admitting_source_concept_id Integer NULL,
-                              discharge_to_source_value Varchar(50) NULL,
-                              discharge_to_concept_id integer NULL,
-                              preceding_visit_detail_id integer NULL,
-                              visit_detail_parent_id integer NULL,
-                              visit_occurrence_id integer NOT NULL );
-
+			visit_detail_id integer NOT NULL,
+			person_id integer NOT NULL,
+			visit_detail_concept_id integer NOT NULL,
+			visit_detail_start_date date NOT NULL,
+			visit_detail_start_datetime TIMESTAMP NULL,
+			visit_detail_end_date date NOT NULL,
+			visit_detail_end_datetime TIMESTAMP NULL,
+			visit_detail_type_concept_id integer NOT NULL,
+			provider_id integer NULL,
+			care_site_id integer NULL,
+			visit_detail_source_value varchar(50) NULL,
+			visit_detail_source_concept_id Integer NULL,
+			admitted_from_concept_id Integer NULL,
+			admitted_from_source_value varchar(50) NULL,
+			discharged_to_source_value varchar(50) NULL,
+			discharged_to_concept_id integer NULL,
+			preceding_visit_detail_id integer NULL,
+			parent_visit_detail_id integer NULL,
+			visit_occurrence_id integer NOT NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
-                                      condition_occurrence_id integer NOT NULL,
-                                      person_id integer NOT NULL,
-                                      condition_concept_id integer NOT NULL,
-                                      condition_start_date date NOT NULL,
-                                      condition_start_datetime TIMESTAMP NULL,
-                                      condition_end_date date NULL,
-                                      condition_end_datetime TIMESTAMP NULL,
-                                      condition_type_concept_id integer NOT NULL,
-                                      condition_status_concept_id integer NULL,
-                                      stop_reason varchar(20) NULL,
-                                      provider_id integer NULL,
-                                      visit_occurrence_id integer NULL,
-                                      visit_detail_id integer NULL,
-                                      condition_source_value varchar(50) NULL,
-                                      condition_source_concept_id integer NULL,
-                                      condition_status_source_value varchar(50) NULL );
-
+			condition_occurrence_id integer NOT NULL,
+			person_id integer NOT NULL,
+			condition_concept_id integer NOT NULL,
+			condition_start_date date NOT NULL,
+			condition_start_datetime TIMESTAMP NULL,
+			condition_end_date date NULL,
+			condition_end_datetime TIMESTAMP NULL,
+			condition_type_concept_id integer NOT NULL,
+			condition_status_concept_id integer NULL,
+			stop_reason varchar(20) NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			condition_source_value varchar(50) NULL,
+			condition_source_concept_id integer NULL,
+			condition_status_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
-                               drug_exposure_id integer NOT NULL,
-                               person_id integer NOT NULL,
-                               drug_concept_id integer NOT NULL,
-                               drug_exposure_start_date date NOT NULL,
-                               drug_exposure_start_datetime TIMESTAMP NULL,
-                               drug_exposure_end_date date NOT NULL,
-                               drug_exposure_end_datetime TIMESTAMP NULL,
-                               verbatim_end_date date NULL,
-                               drug_type_concept_id integer NOT NULL,
-                               stop_reason varchar(20) NULL,
-                               refills integer NULL,
-                               quantity NUMERIC NULL,
-                               days_supply integer NULL,
-                               sig TEXT NULL,
-                               route_concept_id integer NULL,
-                               lot_number varchar(50) NULL,
-                               provider_id integer NULL,
-                               visit_occurrence_id integer NULL,
-                               visit_detail_id integer NULL,
-                               drug_source_value varchar(50) NULL,
-                               drug_source_concept_id integer NULL,
-                               route_source_value varchar(50) NULL,
-                               dose_unit_source_value varchar(50) NULL );
-
+			drug_exposure_id integer NOT NULL,
+			person_id integer NOT NULL,
+			drug_concept_id integer NOT NULL,
+			drug_exposure_start_date date NOT NULL,
+			drug_exposure_start_datetime TIMESTAMP NULL,
+			drug_exposure_end_date date NOT NULL,
+			drug_exposure_end_datetime TIMESTAMP NULL,
+			verbatim_end_date date NULL,
+			drug_type_concept_id integer NOT NULL,
+			stop_reason varchar(20) NULL,
+			refills integer NULL,
+			quantity NUMERIC NULL,
+			days_supply integer NULL,
+			sig TEXT NULL,
+			route_concept_id integer NULL,
+			lot_number varchar(50) NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			drug_source_value varchar(50) NULL,
+			drug_source_concept_id integer NULL,
+			route_source_value varchar(50) NULL,
+			dose_unit_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
-                                      procedure_occurrence_id integer NOT NULL,
-                                      person_id integer NOT NULL,
-                                      procedure_concept_id integer NOT NULL,
-                                      procedure_date date NOT NULL,
-                                      procedure_datetime TIMESTAMP NULL,
-                                      procedure_type_concept_id integer NOT NULL,
-                                      modifier_concept_id integer NULL,
-                                      quantity integer NULL,
-                                      provider_id integer NULL,
-                                      visit_occurrence_id integer NULL,
-                                      visit_detail_id integer NULL,
-                                      procedure_source_value varchar(50) NULL,
-                                      procedure_source_concept_id integer NULL,
-                                      modifier_source_value varchar(50) NULL );
-
+			procedure_occurrence_id integer NOT NULL,
+			person_id integer NOT NULL,
+			procedure_concept_id integer NOT NULL,
+			procedure_date date NOT NULL,
+			procedure_datetime TIMESTAMP NULL,
+			procedure_end_date date NULL,
+			procedure_end_datetime TIMESTAMP NULL,
+			procedure_type_concept_id integer NOT NULL,
+			modifier_concept_id integer NULL,
+			quantity integer NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			procedure_source_value varchar(50) NULL,
+			procedure_source_concept_id integer NULL,
+			modifier_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
-                                 device_exposure_id integer NOT NULL,
-                                 person_id integer NOT NULL,
-                                 device_concept_id integer NOT NULL,
-                                 device_exposure_start_date date NOT NULL,
-                                 device_exposure_start_datetime TIMESTAMP NULL,
-                                 device_exposure_end_date date NULL,
-                                 device_exposure_end_datetime TIMESTAMP NULL,
-                                 device_type_concept_id integer NOT NULL,
-                                 unique_device_id varchar(50) NULL,
-                                 quantity integer NULL,
-                                 provider_id integer NULL,
-                                 visit_occurrence_id integer NULL,
-                                 visit_detail_id integer NULL,
-                                 device_source_value varchar(50) NULL,
-                                 device_source_concept_id integer NULL );
-
+			device_exposure_id integer NOT NULL,
+			person_id integer NOT NULL,
+			device_concept_id integer NOT NULL,
+			device_exposure_start_date date NOT NULL,
+			device_exposure_start_datetime TIMESTAMP NULL,
+			device_exposure_end_date date NULL,
+			device_exposure_end_datetime TIMESTAMP NULL,
+			device_type_concept_id integer NOT NULL,
+			unique_device_id varchar(255) NULL,
+			production_id varchar(255) NULL,
+			quantity integer NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			device_source_value varchar(50) NULL,
+			device_source_concept_id integer NULL,
+			unit_concept_id integer NULL,
+			unit_source_value varchar(50) NULL,
+			unit_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
-                             measurement_id integer NOT NULL,
-                             person_id integer NOT NULL,
-                             measurement_concept_id integer NOT NULL,
-                             measurement_date date NOT NULL,
-                             measurement_datetime TIMESTAMP NULL,
-                             measurement_time varchar(10) NULL,
-                             measurement_type_concept_id integer NOT NULL,
-                             operator_concept_id integer NULL,
-                             value_as_number NUMERIC NULL,
-                             value_as_concept_id integer NULL,
-                             unit_concept_id integer NULL,
-                             range_low NUMERIC NULL,
-                             range_high NUMERIC NULL,
-                             provider_id integer NULL,
-                             visit_occurrence_id integer NULL,
-                             visit_detail_id integer NULL,
-                             measurement_source_value varchar(50) NULL,
-                             measurement_source_concept_id integer NULL,
-                             unit_source_value varchar(50) NULL,
-                             value_source_value varchar(50) NULL );
-
+			measurement_id integer NOT NULL,
+			person_id integer NOT NULL,
+			measurement_concept_id integer NOT NULL,
+			measurement_date date NOT NULL,
+			measurement_datetime TIMESTAMP NULL,
+			measurement_time varchar(10) NULL,
+			measurement_type_concept_id integer NOT NULL,
+			operator_concept_id integer NULL,
+			value_as_number NUMERIC NULL,
+			value_as_concept_id integer NULL,
+			unit_concept_id integer NULL,
+			range_low NUMERIC NULL,
+			range_high NUMERIC NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			measurement_source_value varchar(50) NULL,
+			measurement_source_concept_id integer NULL,
+			unit_source_value varchar(50) NULL,
+			unit_source_concept_id integer NULL,
+			value_source_value varchar(50) NULL,
+			measurement_event_id integer NULL,
+			meas_event_field_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
-                             observation_id integer NOT NULL,
-                             person_id integer NOT NULL,
-                             observation_concept_id integer NOT NULL,
-                             observation_date date NOT NULL,
-                             observation_datetime TIMESTAMP NULL,
-                             observation_type_concept_id integer NOT NULL,
-                             value_as_number NUMERIC NULL,
-                             value_as_string varchar(60) NULL,
-                             value_as_concept_id Integer NULL,
-                             qualifier_concept_id integer NULL,
-                             unit_concept_id integer NULL,
-                             provider_id integer NULL,
-                             visit_occurrence_id integer NULL,
-                             visit_detail_id integer NULL,
-                             observation_source_value varchar(50) NULL,
-                             observation_source_concept_id integer NULL,
-                             unit_source_value varchar(50) NULL,
-                             qualifier_source_value varchar(50) NULL );
-
+			observation_id integer NOT NULL,
+			person_id integer NOT NULL,
+			observation_concept_id integer NOT NULL,
+			observation_date date NOT NULL,
+			observation_datetime TIMESTAMP NULL,
+			observation_type_concept_id integer NOT NULL,
+			value_as_number NUMERIC NULL,
+			value_as_string varchar(60) NULL,
+			value_as_concept_id Integer NULL,
+			qualifier_concept_id integer NULL,
+			unit_concept_id integer NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			observation_source_value varchar(50) NULL,
+			observation_source_concept_id integer NULL,
+			unit_source_value varchar(50) NULL,
+			qualifier_source_value varchar(50) NULL,
+			value_source_value varchar(50) NULL,
+			observation_event_id integer NULL,
+			obs_event_field_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEATH (
-                       person_id integer NOT NULL,
-                       death_date date NOT NULL,
-                       death_datetime TIMESTAMP NULL,
-                       death_type_concept_id integer NULL,
-                       cause_concept_id integer NULL,
-                       cause_source_value varchar(50) NULL,
-                       cause_source_concept_id integer NULL );
-
+			person_id integer NOT NULL,
+			death_date date NOT NULL,
+			death_datetime TIMESTAMP NULL,
+			death_type_concept_id integer NULL,
+			cause_concept_id integer NULL,
+			cause_source_value varchar(50) NULL,
+			cause_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.NOTE (
-                      note_id integer NOT NULL,
-                      person_id integer NOT NULL,
-                      note_date date NOT NULL,
-                      note_datetime TIMESTAMP NULL,
-                      note_type_concept_id integer NOT NULL,
-                      note_class_concept_id integer NOT NULL,
-                      note_title varchar(250) NULL,
-                      note_text TEXT NOT NULL,
-                      encoding_concept_id integer NOT NULL,
-                      language_concept_id integer NOT NULL,
-                      provider_id integer NULL,
-                      visit_occurrence_id integer NULL,
-                      visit_detail_id integer NULL,
-                      note_source_value varchar(50) NULL );
-
+			note_id integer NOT NULL,
+			person_id integer NOT NULL,
+			note_date date NOT NULL,
+			note_datetime TIMESTAMP NULL,
+			note_type_concept_id integer NOT NULL,
+			note_class_concept_id integer NOT NULL,
+			note_title varchar(250) NULL,
+			note_text TEXT NOT NULL,
+			encoding_concept_id integer NOT NULL,
+			language_concept_id integer NOT NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			note_source_value varchar(50) NULL,
+			note_event_id integer NULL,
+			note_event_field_concept_id integer NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
-                          note_nlp_id integer NOT NULL,
-                          note_id integer NOT NULL,
-                          section_concept_id integer NULL,
-                          snippet varchar(250) NULL,
-                          "offset" varchar(50) NULL,
-                          lexical_variant varchar(250) NOT NULL,
-                          note_nlp_concept_id integer NULL,
-                          note_nlp_source_concept_id integer NULL,
-                          nlp_system varchar(250) NULL,
-                          nlp_date date NOT NULL,
-                          nlp_datetime TIMESTAMP NULL,
-                          term_exists varchar(1) NULL,
-                          term_temporal varchar(50) NULL,
-                          term_modifiers varchar(2000) NULL );
-
+			note_nlp_id integer NOT NULL,
+			note_id integer NOT NULL,
+			section_concept_id integer NULL,
+			snippet varchar(250) NULL,
+			"offset" varchar(50) NULL,
+			lexical_variant varchar(250) NOT NULL,
+			note_nlp_concept_id integer NULL,
+			note_nlp_source_concept_id integer NULL,
+			nlp_system varchar(250) NULL,
+			nlp_date date NOT NULL,
+			nlp_datetime TIMESTAMP NULL,
+			term_exists varchar(1) NULL,
+			term_temporal varchar(50) NULL,
+			term_modifiers varchar(2000) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
-                          specimen_id integer NOT NULL,
-                          person_id integer NOT NULL,
-                          specimen_concept_id integer NOT NULL,
-                          specimen_type_concept_id integer NOT NULL,
-                          specimen_date date NOT NULL,
-                          specimen_datetime TIMESTAMP NULL,
-                          quantity NUMERIC NULL,
-                          unit_concept_id integer NULL,
-                          anatomic_site_concept_id integer NULL,
-                          disease_status_concept_id integer NULL,
-                          specimen_source_id varchar(50) NULL,
-                          specimen_source_value varchar(50) NULL,
-                          unit_source_value varchar(50) NULL,
-                          anatomic_site_source_value varchar(50) NULL,
-                          disease_status_source_value varchar(50) NULL );
-
+			specimen_id integer NOT NULL,
+			person_id integer NOT NULL,
+			specimen_concept_id integer NOT NULL,
+			specimen_type_concept_id integer NOT NULL,
+			specimen_date date NOT NULL,
+			specimen_datetime TIMESTAMP NULL,
+			quantity NUMERIC NULL,
+			unit_concept_id integer NULL,
+			anatomic_site_concept_id integer NULL,
+			disease_status_concept_id integer NULL,
+			specimen_source_id varchar(50) NULL,
+			specimen_source_value varchar(50) NULL,
+			unit_source_value varchar(50) NULL,
+			anatomic_site_source_value varchar(50) NULL,
+			disease_status_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
-                                   domain_concept_id_1 integer NOT NULL,
-                                   fact_id_1 integer NOT NULL,
-                                   domain_concept_id_2 integer NOT NULL,
-                                   fact_id_2 integer NOT NULL,
-                                   relationship_concept_id integer NOT NULL );
-
+			domain_concept_id_1 integer NOT NULL,
+			fact_id_1 integer NOT NULL,
+			domain_concept_id_2 integer NOT NULL,
+			fact_id_2 integer NOT NULL,
+			relationship_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.LOCATION (
-                          location_id integer NOT NULL,
-                          address_1 varchar(50) NULL,
-                          address_2 varchar(50) NULL,
-                          city varchar(50) NULL,
-                          state varchar(2) NULL,
-                          zip varchar(9) NULL,
-                          county varchar(20) NULL,
-                          location_source_value varchar(50) NULL );
-
+			location_id integer NOT NULL,
+			address_1 varchar(50) NULL,
+			address_2 varchar(50) NULL,
+			city varchar(50) NULL,
+			state varchar(2) NULL,
+			zip varchar(9) NULL,
+			county varchar(20) NULL,
+			location_source_value varchar(50) NULL,
+			country_concept_id integer NULL,
+			country_source_value varchar(80) NULL,
+			latitude NUMERIC NULL,
+			longitude NUMERIC NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
-                           care_site_id integer NOT NULL,
-                           care_site_name varchar(255) NULL,
-                           place_of_service_concept_id integer NULL,
-                           location_id integer NULL,
-                           care_site_source_value varchar(50) NULL,
-                           place_of_service_source_value varchar(50) NULL );
-
+			care_site_id integer NOT NULL,
+			care_site_name varchar(255) NULL,
+			place_of_service_concept_id integer NULL,
+			location_id integer NULL,
+			care_site_source_value varchar(50) NULL,
+			place_of_service_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.PROVIDER (
-                          provider_id integer NOT NULL,
-                          provider_name varchar(255) NULL,
-                          npi varchar(20) NULL,
-                          dea varchar(20) NULL,
-                          specialty_concept_id integer NULL,
-                          care_site_id integer NULL,
-                          year_of_birth integer NULL,
-                          gender_concept_id integer NULL,
-                          provider_source_value varchar(50) NULL,
-                          specialty_source_value varchar(50) NULL,
-                          specialty_source_concept_id integer NULL,
-                          gender_source_value varchar(50) NULL,
-                          gender_source_concept_id integer NULL );
-
+			provider_id integer NOT NULL,
+			provider_name varchar(255) NULL,
+			npi varchar(20) NULL,
+			dea varchar(20) NULL,
+			specialty_concept_id integer NULL,
+			care_site_id integer NULL,
+			year_of_birth integer NULL,
+			gender_concept_id integer NULL,
+			provider_source_value varchar(50) NULL,
+			specialty_source_value varchar(50) NULL,
+			specialty_source_concept_id integer NULL,
+			gender_source_value varchar(50) NULL,
+			gender_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
-                                   payer_plan_period_id integer NOT NULL,
-                                   person_id integer NOT NULL,
-                                   payer_plan_period_start_date date NOT NULL,
-                                   payer_plan_period_end_date date NOT NULL,
-                                   payer_concept_id integer NULL,
-                                   payer_source_value varchar(50) NULL,
-                                   payer_source_concept_id integer NULL,
-                                   plan_concept_id integer NULL,
-                                   plan_source_value varchar(50) NULL,
-                                   plan_source_concept_id integer NULL,
-                                   sponsor_concept_id integer NULL,
-                                   sponsor_source_value varchar(50) NULL,
-                                   sponsor_source_concept_id integer NULL,
-                                   family_source_value varchar(50) NULL,
-                                   stop_reason_concept_id integer NULL,
-                                   stop_reason_source_value varchar(50) NULL,
-                                   stop_reason_source_concept_id integer NULL );
-
+			payer_plan_period_id integer NOT NULL,
+			person_id integer NOT NULL,
+			payer_plan_period_start_date date NOT NULL,
+			payer_plan_period_end_date date NOT NULL,
+			payer_concept_id integer NULL,
+			payer_source_value varchar(50) NULL,
+			payer_source_concept_id integer NULL,
+			plan_concept_id integer NULL,
+			plan_source_value varchar(50) NULL,
+			plan_source_concept_id integer NULL,
+			sponsor_concept_id integer NULL,
+			sponsor_source_value varchar(50) NULL,
+			sponsor_source_concept_id integer NULL,
+			family_source_value varchar(50) NULL,
+			stop_reason_concept_id integer NULL,
+			stop_reason_source_value varchar(50) NULL,
+			stop_reason_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COST (
-                      cost_id integer NOT NULL,
-                      cost_event_id integer NOT NULL,
-                      cost_domain_id varchar(20) NOT NULL,
-                      cost_type_concept_id integer NOT NULL,
-                      currency_concept_id integer NULL,
-                      total_charge NUMERIC NULL,
-                      total_cost NUMERIC NULL,
-                      total_paid NUMERIC NULL,
-                      paid_by_payer NUMERIC NULL,
-                      paid_by_patient NUMERIC NULL,
-                      paid_patient_copay NUMERIC NULL,
-                      paid_patient_coinsurance NUMERIC NULL,
-                      paid_patient_deductible NUMERIC NULL,
-                      paid_by_primary NUMERIC NULL,
-                      paid_ingredient_cost NUMERIC NULL,
-                      paid_dispensing_fee NUMERIC NULL,
-                      payer_plan_period_id integer NULL,
-                      amount_allowed NUMERIC NULL,
-                      revenue_code_concept_id integer NULL,
-                      revenue_code_source_value varchar(50) NULL,
-                      drg_concept_id integer NULL,
-                      drg_source_value varchar(3) NULL );
-
+			cost_id integer NOT NULL,
+			cost_event_id integer NOT NULL,
+			cost_domain_id varchar(20) NOT NULL,
+			cost_type_concept_id integer NOT NULL,
+			currency_concept_id integer NULL,
+			total_charge NUMERIC NULL,
+			total_cost NUMERIC NULL,
+			total_paid NUMERIC NULL,
+			paid_by_payer NUMERIC NULL,
+			paid_by_patient NUMERIC NULL,
+			paid_patient_copay NUMERIC NULL,
+			paid_patient_coinsurance NUMERIC NULL,
+			paid_patient_deductible NUMERIC NULL,
+			paid_by_primary NUMERIC NULL,
+			paid_ingredient_cost NUMERIC NULL,
+			paid_dispensing_fee NUMERIC NULL,
+			payer_plan_period_id integer NULL,
+			amount_allowed NUMERIC NULL,
+			revenue_code_concept_id integer NULL,
+			revenue_code_source_value varchar(50) NULL,
+			drg_concept_id integer NULL,
+			drg_source_value varchar(3) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
-                          drug_era_id integer NOT NULL,
-                          person_id integer NOT NULL,
-                          drug_concept_id integer NOT NULL,
-                          drug_era_start_date TIMESTAMP NOT NULL,
-                          drug_era_end_date TIMESTAMP NOT NULL,
-                          drug_exposure_count integer NULL,
-                          gap_days integer NULL );
-
+			drug_era_id integer NOT NULL,
+			person_id integer NOT NULL,
+			drug_concept_id integer NOT NULL,
+			drug_era_start_date date NOT NULL,
+			drug_era_end_date date NOT NULL,
+			drug_exposure_count integer NULL,
+			gap_days integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
-                          dose_era_id integer NOT NULL,
-                          person_id integer NOT NULL,
-                          drug_concept_id integer NOT NULL,
-                          unit_concept_id integer NOT NULL,
-                          dose_value NUMERIC NOT NULL,
-                          dose_era_start_date TIMESTAMP NOT NULL,
-                          dose_era_end_date TIMESTAMP NOT NULL );
-
+			dose_era_id integer NOT NULL,
+			person_id integer NOT NULL,
+			drug_concept_id integer NOT NULL,
+			unit_concept_id integer NOT NULL,
+			dose_value NUMERIC NOT NULL,
+			dose_era_start_date date NOT NULL,
+			dose_era_end_date date NOT NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
-                               condition_era_id integer NOT NULL,
-                               person_id integer NOT NULL,
-                               condition_concept_id integer NOT NULL,
-                               condition_era_start_date TIMESTAMP NOT NULL,
-                               condition_era_end_date TIMESTAMP NOT NULL,
-                               condition_occurrence_count integer NULL );
-
+			condition_era_id integer NOT NULL,
+			person_id integer NOT NULL,
+			condition_concept_id integer NOT NULL,
+			condition_era_start_date date NOT NULL,
+			condition_era_end_date date NOT NULL,
+			condition_occurrence_count integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
+CREATE TABLE @cdmDatabaseSchema.EPISODE (
+			episode_id integer NOT NULL,
+			person_id integer NOT NULL,
+			episode_concept_id integer NOT NULL,
+			episode_start_date date NOT NULL,
+			episode_start_datetime TIMESTAMP NULL,
+			episode_end_date date NULL,
+			episode_end_datetime TIMESTAMP NULL,
+			episode_parent_id integer NULL,
+			episode_number integer NULL,
+			episode_object_concept_id integer NOT NULL,
+			episode_type_concept_id integer NOT NULL,
+			episode_source_value varchar(50) NULL,
+			episode_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON RANDOM
+CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT (
+			episode_id integer NOT NULL,
+			event_id integer NOT NULL,
+			episode_event_field_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.METADATA (
-                          metadata_concept_id integer NOT NULL,
-                          metadata_type_concept_id integer NOT NULL,
-                          name varchar(250) NOT NULL,
-                          value_as_string varchar(250) NULL,
-                          value_as_concept_id integer NULL,
-                          metadata_date date NULL,
-                          metadata_datetime TIMESTAMP NULL );
-
+			metadata_id integer NOT NULL,
+			metadata_concept_id integer NOT NULL,
+			metadata_type_concept_id integer NOT NULL,
+			name varchar(250) NOT NULL,
+			value_as_string varchar(250) NULL,
+			value_as_concept_id integer NULL,
+			value_as_number NUMERIC NULL,
+			metadata_date date NULL,
+			metadata_datetime TIMESTAMP NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
-                            cdm_source_name varchar(255) NOT NULL,
-                            cdm_source_abbreviation varchar(25) NULL,
-                            cdm_holder varchar(255) NULL,
-                            source_description TEXT NULL,
-                            source_documentation_reference varchar(255) NULL,
-                            cdm_etl_reference varchar(255) NULL,
-                            source_release_date date NULL,
-                            cdm_release_date date NULL,
-                            cdm_version varchar(10) NULL,
-                            vocabulary_version varchar(20) NULL );
-
+			cdm_source_name varchar(255) NOT NULL,
+			cdm_source_abbreviation varchar(25) NOT NULL,
+			cdm_holder varchar(255) NOT NULL,
+			source_description TEXT NULL,
+			source_documentation_reference varchar(255) NULL,
+			cdm_etl_reference varchar(255) NULL,
+			source_release_date date NOT NULL,
+			cdm_release_date date NOT NULL,
+			cdm_version varchar(10) NULL,
+			cdm_version_concept_id integer NOT NULL,
+			vocabulary_version varchar(20) NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT (
-                         concept_id integer NOT NULL,
-                         concept_name varchar(255) NOT NULL,
-                         domain_id varchar(20) NOT NULL,
-                         vocabulary_id varchar(20) NOT NULL,
-                         concept_class_id varchar(20) NOT NULL,
-                         standard_concept varchar(1) NULL,
-                         concept_code varchar(50) NOT NULL,
-                         valid_start_date date NOT NULL,
-                         valid_end_date date NOT NULL,
-                         invalid_reason varchar(1) NULL );
-
+			concept_id integer NOT NULL,
+			concept_name varchar(255) NOT NULL,
+			domain_id varchar(20) NOT NULL,
+			vocabulary_id varchar(20) NOT NULL,
+			concept_class_id varchar(20) NOT NULL,
+			standard_concept varchar(1) NULL,
+			concept_code varchar(50) NOT NULL,
+			valid_start_date date NOT NULL,
+			valid_end_date date NOT NULL,
+			invalid_reason varchar(1) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
-                            vocabulary_id varchar(20) NOT NULL,
-                            vocabulary_name varchar(255) NOT NULL,
-                            vocabulary_reference varchar(255) NOT NULL,
-                            vocabulary_version varchar(255) NULL,
-                            vocabulary_concept_id integer NOT NULL );
-
+			vocabulary_id varchar(20) NOT NULL,
+			vocabulary_name varchar(255) NOT NULL,
+			vocabulary_reference varchar(255) NULL,
+			vocabulary_version varchar(255) NULL,
+			vocabulary_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DOMAIN (
-                        domain_id varchar(20) NOT NULL,
-                        domain_name varchar(255) NOT NULL,
-                        domain_concept_id integer NOT NULL );
-
+			domain_id varchar(20) NOT NULL,
+			domain_name varchar(255) NOT NULL,
+			domain_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS (
-                               concept_class_id varchar(20) NOT NULL,
-                               concept_class_name varchar(255) NOT NULL,
-                               concept_class_concept_id integer NOT NULL );
-
+			concept_class_id varchar(20) NOT NULL,
+			concept_class_name varchar(255) NOT NULL,
+			concept_class_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
-                                      concept_id_1 integer NOT NULL,
-                                      concept_id_2 integer NOT NULL,
-                                      relationship_id varchar(20) NOT NULL,
-                                      valid_start_date date NOT NULL,
-                                      valid_end_date date NOT NULL,
-                                      invalid_reason varchar(1) NULL );
-
+			concept_id_1 integer NOT NULL,
+			concept_id_2 integer NOT NULL,
+			relationship_id varchar(20) NOT NULL,
+			valid_start_date date NOT NULL,
+			valid_end_date date NOT NULL,
+			invalid_reason varchar(1) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
-                              relationship_id varchar(20) NOT NULL,
-                              relationship_name varchar(255) NOT NULL,
-                              is_hierarchical varchar(1) NOT NULL,
-                              defines_ancestry varchar(1) NOT NULL,
-                              reverse_relationship_id varchar(20) NOT NULL,
-                              relationship_concept_id integer NOT NULL );
-
+			relationship_id varchar(20) NOT NULL,
+			relationship_name varchar(255) NOT NULL,
+			is_hierarchical varchar(1) NOT NULL,
+			defines_ancestry varchar(1) NOT NULL,
+			reverse_relationship_id varchar(20) NOT NULL,
+			relationship_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM (
-                                 concept_id integer NOT NULL,
-                                 concept_synonym_name varchar(1000) NOT NULL,
-                                 language_concept_id integer NOT NULL );
-
+			concept_id integer NOT NULL,
+			concept_synonym_name varchar(1000) NOT NULL,
+			language_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR (
-                                  ancestor_concept_id integer NOT NULL,
-                                  descendant_concept_id integer NOT NULL,
-                                  min_levels_of_separation integer NOT NULL,
-                                  max_levels_of_separation integer NOT NULL );
-
+			ancestor_concept_id integer NOT NULL,
+			descendant_concept_id integer NOT NULL,
+			min_levels_of_separation integer NOT NULL,
+			max_levels_of_separation integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
-                                       source_code varchar(50) NOT NULL,
-                                       source_concept_id integer NOT NULL,
-                                       source_vocabulary_id varchar(20) NOT NULL,
-                                       source_code_description varchar(255) NULL,
-                                       target_concept_id integer NOT NULL,
-                                       target_vocabulary_id varchar(20) NOT NULL,
-                                       valid_start_date date NOT NULL,
-                                       valid_end_date date NOT NULL,
-                                       invalid_reason varchar(1) NULL );
-
+			source_code varchar(50) NOT NULL,
+			source_concept_id integer NOT NULL,
+			source_vocabulary_id varchar(20) NOT NULL,
+			source_code_description varchar(255) NULL,
+			target_concept_id integer NOT NULL,
+			target_vocabulary_id varchar(20) NOT NULL,
+			valid_start_date date NOT NULL,
+			valid_end_date date NOT NULL,
+			invalid_reason varchar(1) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
-                               drug_concept_id integer NOT NULL,
-                               ingredient_concept_id integer NOT NULL,
-                               amount_value NUMERIC NULL,
-                               amount_unit_concept_id integer NULL,
-                               numerator_value NUMERIC NULL,
-                               numerator_unit_concept_id integer NULL,
-                               denominator_value NUMERIC NULL,
-                               denominator_unit_concept_id integer NULL,
-                               box_size integer NULL,
-                               valid_start_date date NOT NULL,
-                               valid_end_date date NOT NULL,
-                               invalid_reason varchar(1) NULL );
-
-CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION (
-                                   cohort_definition_id integer NOT NULL,
-                                   cohort_definition_name varchar(255) NOT NULL,
-                                   cohort_definition_description TEXT NULL,
-                                   definition_type_concept_id integer NOT NULL,
-                                   cohort_definition_syntax TEXT NULL,
-                                   subject_concept_id integer NOT NULL,
-                                   cohort_initiation_date date NULL );
-
-CREATE TABLE @cdmDatabaseSchema.ATTRIBUTE_DEFINITION (
-                                      attribute_definition_id integer NOT NULL,
-                                      attribute_name varchar(255) NOT NULL,
-                                      attribute_description TEXT NULL,
-                                      attribute_type_concept_id integer NOT NULL,
-                                      attribute_syntax TEXT NULL );
-
+			drug_concept_id integer NOT NULL,
+			ingredient_concept_id integer NOT NULL,
+			amount_value NUMERIC NULL,
+			amount_unit_concept_id integer NULL,
+			numerator_value NUMERIC NULL,
+			numerator_unit_concept_id integer NULL,
+			denominator_value NUMERIC NULL,
+			denominator_unit_concept_id integer NULL,
+			box_size integer NULL,
+			valid_start_date date NOT NULL,
+			valid_end_date date NOT NULL,
+			invalid_reason varchar(1) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT (
-                                           cohort_definition_id integer NOT NULL,
-                                           subject_id integer NOT NULL,
-                                           cohort_start_date date NOT NULL,
-                                           cohort_end_date date NOT NULL );
+			cohort_definition_id integer NOT NULL,
+			subject_id integer NOT NULL,
+			cohort_start_date date NOT NULL,
+			cohort_end_date date NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
+CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION (
+			cohort_definition_id integer NOT NULL,
+			cohort_definition_name varchar(255) NOT NULL,
+			cohort_definition_description TEXT NULL,
+			definition_type_concept_id integer NOT NULL,
+			cohort_definition_syntax TEXT NULL,
+			subject_concept_id integer NOT NULL,
+			cohort_initiation_date date NULL );
\ No newline at end of file
diff --git a/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_indices.sql b/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_indices.sql
index 09de8a4b..243bad09 100644
--- a/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_indices.sql
+++ b/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_indices.sql
@@ -1 +1,98 @@
+/*snowflake OMOP CDM Indices
+  There are no unique indices created because it is assumed that the primary key constraints have been run prior to
+  implementing indices.
+*/
+/************************
+Standardized clinical data
+************************/
 -- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+/************************
+Standardized health system data
+************************/
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+/************************
+Standardized health economics
+************************/
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+/************************
+Standardized derived elements
+************************/
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+/**************************
+Standardized meta-data
+***************************/
+-- snowflake does not support indexes
+/**************************
+Standardized vocabularies
+***************************/
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+-- snowflake does not support indexes
+--Additional v6.0 indices
+--CREATE CLUSTERED INDEX idx_survey_person_id_1 ON @cdmDatabaseSchema.survey_conduct (person_id ASC);
+--CREATE CLUSTERED INDEX idx_episode_person_id_1 ON @cdmDatabaseSchema.episode (person_id ASC);
+--CREATE INDEX idx_episode_concept_id_1 ON @cdmDatabaseSchema.episode (episode_concept_id ASC);
+--CREATE CLUSTERED INDEX idx_episode_event_id_1 ON @cdmDatabaseSchema.episode_event (episode_id ASC);
+--CREATE INDEX idx_ee_field_concept_id_1 ON @cdmDatabaseSchema.episode_event (event_field_concept_id ASC);
diff --git a/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_primary_keys.sql b/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_primary_keys.sql
index 05c804f2..bb5311ab 100644
--- a/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_primary_keys.sql
+++ b/inst/ddl/5.4/snowflake/OMOPCDM_snowflake_5.4_primary_keys.sql
@@ -1,3 +1,4 @@
+--snowflake CDM Primary Key Constraints for OMOP Common Data Model 5.4
 ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT xpk_PERSON PRIMARY KEY (person_id);
 ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT xpk_OBSERVATION_PERIOD PRIMARY KEY (observation_period_id);
 ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT xpk_VISIT_OCCURRENCE PRIMARY KEY (visit_occurrence_id);
@@ -19,8 +20,10 @@ ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT xpk_COST PRIMARY KEY (cost_id
 ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT xpk_DRUG_ERA PRIMARY KEY (drug_era_id);
 ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT xpk_DOSE_ERA PRIMARY KEY (dose_era_id);
 ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT xpk_CONDITION_ERA PRIMARY KEY (condition_era_id);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT xpk_EPISODE PRIMARY KEY (episode_id);
+ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT xpk_METADATA PRIMARY KEY (metadata_id);
 ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT xpk_CONCEPT PRIMARY KEY (concept_id);
 ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT xpk_VOCABULARY PRIMARY KEY (vocabulary_id);
 ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT xpk_DOMAIN PRIMARY KEY (domain_id);
 ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT xpk_CONCEPT_CLASS PRIMARY KEY (concept_class_id);
-ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY (relationship_id);
\ No newline at end of file
+ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY (relationship_id);
diff --git a/inst/ddl/5.4/spark/OMOPCDM_spark_5.4_ddl.sql b/inst/ddl/5.4/spark/OMOPCDM_spark_5.4_ddl.sql
index cc742531..7af24e85 100644
--- a/inst/ddl/5.4/spark/OMOPCDM_spark_5.4_ddl.sql
+++ b/inst/ddl/5.4/spark/OMOPCDM_spark_5.4_ddl.sql
@@ -1,8 +1,9 @@
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.PERSON 
+CREATE TABLE @cdmDatabaseSchema.PERSON  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS person_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS gender_concept_id,
 	CAST(NULL AS integer) AS year_of_birth,
 	CAST(NULL AS integer) AS month_of_birth,
@@ -19,21 +20,23 @@ SELECT 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS STRING) AS race_source_value,
 	CAST(NULL AS integer) AS race_source_concept_id,
 	CAST(NULL AS STRING) AS ethnicity_source_value,
-	CAST(NULL AS integer) AS ethnicity_source_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS ethnicity_source_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD 
+CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS observation_period_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS observation_period_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS date) AS observation_period_start_date,
 	CAST(NULL AS date) AS observation_period_end_date,
-	CAST(NULL AS integer) AS period_type_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS period_type_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE 
+CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS visit_occurrence_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS visit_occurrence_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS visit_concept_id,
 	CAST(NULL AS date) AS visit_start_date,
@@ -49,12 +52,13 @@ SELECT 	CAST(NULL AS integer) AS visit_occurrence_id,
 	CAST(NULL AS STRING) AS admitted_from_source_value,
 	CAST(NULL AS integer) AS discharged_to_concept_id,
 	CAST(NULL AS STRING) AS discharged_to_source_value,
-	CAST(NULL AS integer) AS preceding_visit_occurrence_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS preceding_visit_occurrence_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL 
+CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS visit_detail_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS visit_detail_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS visit_detail_concept_id,
 	CAST(NULL AS date) AS visit_detail_start_date,
@@ -72,12 +76,13 @@ SELECT 	CAST(NULL AS integer) AS visit_detail_id,
 	CAST(NULL AS integer) AS discharged_to_concept_id,
 	CAST(NULL AS integer) AS preceding_visit_detail_id,
 	CAST(NULL AS integer) AS parent_visit_detail_id,
-	CAST(NULL AS integer) AS visit_occurrence_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS visit_occurrence_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE 
+CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS condition_occurrence_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS condition_occurrence_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS condition_concept_id,
 	CAST(NULL AS date) AS condition_start_date,
@@ -92,12 +97,13 @@ SELECT 	CAST(NULL AS integer) AS condition_occurrence_id,
 	CAST(NULL AS integer) AS visit_detail_id,
 	CAST(NULL AS STRING) AS condition_source_value,
 	CAST(NULL AS integer) AS condition_source_concept_id,
-	CAST(NULL AS STRING) AS condition_status_source_value WHERE 1 = 0;
+	CAST(NULL AS STRING) AS condition_status_source_value  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE 
+CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS drug_exposure_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS drug_exposure_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS drug_concept_id,
 	CAST(NULL AS date) AS drug_exposure_start_date,
@@ -119,12 +125,13 @@ SELECT 	CAST(NULL AS integer) AS drug_exposure_id,
 	CAST(NULL AS STRING) AS drug_source_value,
 	CAST(NULL AS integer) AS drug_source_concept_id,
 	CAST(NULL AS STRING) AS route_source_value,
-	CAST(NULL AS STRING) AS dose_unit_source_value WHERE 1 = 0;
+	CAST(NULL AS STRING) AS dose_unit_source_value  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE 
+CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS procedure_occurrence_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS procedure_occurrence_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS procedure_concept_id,
 	CAST(NULL AS date) AS procedure_date,
@@ -139,12 +146,13 @@ SELECT 	CAST(NULL AS integer) AS procedure_occurrence_id,
 	CAST(NULL AS integer) AS visit_detail_id,
 	CAST(NULL AS STRING) AS procedure_source_value,
 	CAST(NULL AS integer) AS procedure_source_concept_id,
-	CAST(NULL AS STRING) AS modifier_source_value WHERE 1 = 0;
+	CAST(NULL AS STRING) AS modifier_source_value  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE 
+CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS device_exposure_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS device_exposure_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS device_concept_id,
 	CAST(NULL AS date) AS device_exposure_start_date,
@@ -162,12 +170,13 @@ SELECT 	CAST(NULL AS integer) AS device_exposure_id,
 	CAST(NULL AS integer) AS device_source_concept_id,
 	CAST(NULL AS integer) AS unit_concept_id,
 	CAST(NULL AS STRING) AS unit_source_value,
-	CAST(NULL AS integer) AS unit_source_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS unit_source_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.MEASUREMENT 
+CREATE TABLE @cdmDatabaseSchema.MEASUREMENT  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS measurement_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS measurement_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS measurement_concept_id,
 	CAST(NULL AS date) AS measurement_date,
@@ -189,12 +198,13 @@ SELECT 	CAST(NULL AS integer) AS measurement_id,
 	CAST(NULL AS integer) AS unit_source_concept_id,
 	CAST(NULL AS STRING) AS value_source_value,
 	CAST(NULL AS integer) AS measurement_event_id,
-	CAST(NULL AS integer) AS meas_event_field_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS meas_event_field_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.OBSERVATION 
+CREATE TABLE @cdmDatabaseSchema.OBSERVATION  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS observation_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS observation_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS observation_concept_id,
 	CAST(NULL AS date) AS observation_date,
@@ -214,23 +224,25 @@ SELECT 	CAST(NULL AS integer) AS observation_id,
 	CAST(NULL AS STRING) AS qualifier_source_value,
 	CAST(NULL AS STRING) AS value_source_value,
 	CAST(NULL AS integer) AS observation_event_id,
-	CAST(NULL AS integer) AS obs_event_field_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS obs_event_field_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.DEATH 
+CREATE TABLE @cdmDatabaseSchema.DEATH  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS person_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS date) AS death_date,
 	CAST(NULL AS TIMESTAMP) AS death_datetime,
 	CAST(NULL AS integer) AS death_type_concept_id,
 	CAST(NULL AS integer) AS cause_concept_id,
 	CAST(NULL AS STRING) AS cause_source_value,
-	CAST(NULL AS integer) AS cause_source_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS cause_source_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.NOTE 
+CREATE TABLE @cdmDatabaseSchema.NOTE  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS note_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS note_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS date) AS note_date,
 	CAST(NULL AS TIMESTAMP) AS note_datetime,
@@ -245,12 +257,13 @@ SELECT 	CAST(NULL AS integer) AS note_id,
 	CAST(NULL AS integer) AS visit_detail_id,
 	CAST(NULL AS STRING) AS note_source_value,
 	CAST(NULL AS integer) AS note_event_id,
-	CAST(NULL AS integer) AS note_event_field_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS note_event_field_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.NOTE_NLP 
+CREATE TABLE @cdmDatabaseSchema.NOTE_NLP  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS note_nlp_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS note_nlp_id,
 	CAST(NULL AS integer) AS note_id,
 	CAST(NULL AS integer) AS section_concept_id,
 	CAST(NULL AS STRING) AS snippet,
@@ -263,12 +276,13 @@ SELECT 	CAST(NULL AS integer) AS note_nlp_id,
 	CAST(NULL AS TIMESTAMP) AS nlp_datetime,
 	CAST(NULL AS STRING) AS term_exists,
 	CAST(NULL AS STRING) AS term_temporal,
-	CAST(NULL AS STRING) AS term_modifiers WHERE 1 = 0;
+	CAST(NULL AS STRING) AS term_modifiers  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.SPECIMEN 
+CREATE TABLE @cdmDatabaseSchema.SPECIMEN  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS specimen_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS specimen_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS specimen_concept_id,
 	CAST(NULL AS integer) AS specimen_type_concept_id,
@@ -282,21 +296,23 @@ SELECT 	CAST(NULL AS integer) AS specimen_id,
 	CAST(NULL AS STRING) AS specimen_source_value,
 	CAST(NULL AS STRING) AS unit_source_value,
 	CAST(NULL AS STRING) AS anatomic_site_source_value,
-	CAST(NULL AS STRING) AS disease_status_source_value WHERE 1 = 0;
+	CAST(NULL AS STRING) AS disease_status_source_value  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP 
+CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS domain_concept_id_1,
+ AS
+SELECT
+CAST(NULL AS integer) AS domain_concept_id_1,
 	CAST(NULL AS integer) AS fact_id_1,
 	CAST(NULL AS integer) AS domain_concept_id_2,
 	CAST(NULL AS integer) AS fact_id_2,
-	CAST(NULL AS integer) AS relationship_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS relationship_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.LOCATION 
+CREATE TABLE @cdmDatabaseSchema.LOCATION  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS location_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS location_id,
 	CAST(NULL AS STRING) AS address_1,
 	CAST(NULL AS STRING) AS address_2,
 	CAST(NULL AS STRING) AS city,
@@ -307,22 +323,24 @@ SELECT 	CAST(NULL AS integer) AS location_id,
 	CAST(NULL AS integer) AS country_concept_id,
 	CAST(NULL AS STRING) AS country_source_value,
 	CAST(NULL AS float) AS latitude,
-	CAST(NULL AS float) AS longitude WHERE 1 = 0;
+	CAST(NULL AS float) AS longitude  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.CARE_SITE 
+CREATE TABLE @cdmDatabaseSchema.CARE_SITE  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS care_site_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS care_site_id,
 	CAST(NULL AS STRING) AS care_site_name,
 	CAST(NULL AS integer) AS place_of_service_concept_id,
 	CAST(NULL AS integer) AS location_id,
 	CAST(NULL AS STRING) AS care_site_source_value,
-	CAST(NULL AS STRING) AS place_of_service_source_value WHERE 1 = 0;
+	CAST(NULL AS STRING) AS place_of_service_source_value  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.PROVIDER 
+CREATE TABLE @cdmDatabaseSchema.PROVIDER  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS provider_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS provider_id,
 	CAST(NULL AS STRING) AS provider_name,
 	CAST(NULL AS STRING) AS npi,
 	CAST(NULL AS STRING) AS dea,
@@ -334,12 +352,13 @@ SELECT 	CAST(NULL AS integer) AS provider_id,
 	CAST(NULL AS STRING) AS specialty_source_value,
 	CAST(NULL AS integer) AS specialty_source_concept_id,
 	CAST(NULL AS STRING) AS gender_source_value,
-	CAST(NULL AS integer) AS gender_source_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS gender_source_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD 
+CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS payer_plan_period_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS payer_plan_period_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS date) AS payer_plan_period_start_date,
 	CAST(NULL AS date) AS payer_plan_period_end_date,
@@ -355,12 +374,13 @@ SELECT 	CAST(NULL AS integer) AS payer_plan_period_id,
 	CAST(NULL AS STRING) AS family_source_value,
 	CAST(NULL AS integer) AS stop_reason_concept_id,
 	CAST(NULL AS STRING) AS stop_reason_source_value,
-	CAST(NULL AS integer) AS stop_reason_source_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS stop_reason_source_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.COST 
+CREATE TABLE @cdmDatabaseSchema.COST  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS cost_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS cost_id,
 	CAST(NULL AS integer) AS cost_event_id,
 	CAST(NULL AS STRING) AS cost_domain_id,
 	CAST(NULL AS integer) AS cost_type_concept_id,
@@ -381,44 +401,48 @@ SELECT 	CAST(NULL AS integer) AS cost_id,
 	CAST(NULL AS integer) AS revenue_code_concept_id,
 	CAST(NULL AS STRING) AS revenue_code_source_value,
 	CAST(NULL AS integer) AS drg_concept_id,
-	CAST(NULL AS STRING) AS drg_source_value WHERE 1 = 0;
+	CAST(NULL AS STRING) AS drg_source_value  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.DRUG_ERA 
+CREATE TABLE @cdmDatabaseSchema.DRUG_ERA  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS drug_era_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS drug_era_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS drug_concept_id,
 	CAST(NULL AS date) AS drug_era_start_date,
 	CAST(NULL AS date) AS drug_era_end_date,
 	CAST(NULL AS integer) AS drug_exposure_count,
-	CAST(NULL AS integer) AS gap_days WHERE 1 = 0;
+	CAST(NULL AS integer) AS gap_days  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.DOSE_ERA 
+CREATE TABLE @cdmDatabaseSchema.DOSE_ERA  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS dose_era_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS dose_era_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS drug_concept_id,
 	CAST(NULL AS integer) AS unit_concept_id,
 	CAST(NULL AS float) AS dose_value,
 	CAST(NULL AS date) AS dose_era_start_date,
-	CAST(NULL AS date) AS dose_era_end_date WHERE 1 = 0;
+	CAST(NULL AS date) AS dose_era_end_date  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA 
+CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS condition_era_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS condition_era_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS condition_concept_id,
 	CAST(NULL AS date) AS condition_era_start_date,
 	CAST(NULL AS date) AS condition_era_end_date,
-	CAST(NULL AS integer) AS condition_occurrence_count WHERE 1 = 0;
+	CAST(NULL AS integer) AS condition_occurrence_count  WHERE 1 = 0;
 --HINT DISTRIBUTE ON KEY (person_id)
-CREATE TABLE @cdmDatabaseSchema.EPISODE 
+CREATE TABLE @cdmDatabaseSchema.EPISODE  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS episode_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS episode_id,
 	CAST(NULL AS integer) AS person_id,
 	CAST(NULL AS integer) AS episode_concept_id,
 	CAST(NULL AS date) AS episode_start_date,
@@ -430,19 +454,21 @@ SELECT 	CAST(NULL AS integer) AS episode_id,
 	CAST(NULL AS integer) AS episode_object_concept_id,
 	CAST(NULL AS integer) AS episode_type_concept_id,
 	CAST(NULL AS STRING) AS episode_source_value,
-	CAST(NULL AS integer) AS episode_source_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS episode_source_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT 
+CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS episode_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS episode_id,
 	CAST(NULL AS integer) AS event_id,
-	CAST(NULL AS integer) AS episode_event_field_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS episode_event_field_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.METADATA 
+CREATE TABLE @cdmDatabaseSchema.METADATA  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS metadata_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS metadata_id,
 	CAST(NULL AS integer) AS metadata_concept_id,
 	CAST(NULL AS integer) AS metadata_type_concept_id,
 	CAST(NULL AS STRING) AS name,
@@ -450,12 +476,13 @@ SELECT 	CAST(NULL AS integer) AS metadata_id,
 	CAST(NULL AS integer) AS value_as_concept_id,
 	CAST(NULL AS float) AS value_as_number,
 	CAST(NULL AS date) AS metadata_date,
-	CAST(NULL AS TIMESTAMP) AS metadata_datetime WHERE 1 = 0;
+	CAST(NULL AS TIMESTAMP) AS metadata_datetime  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE 
+CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS STRING) AS cdm_source_name,
+ AS
+SELECT
+CAST(NULL AS STRING) AS cdm_source_name,
 	CAST(NULL AS STRING) AS cdm_source_abbreviation,
 	CAST(NULL AS STRING) AS cdm_holder,
 	CAST(NULL AS STRING) AS source_description,
@@ -465,12 +492,13 @@ SELECT 	CAST(NULL AS STRING) AS cdm_source_name,
 	CAST(NULL AS date) AS cdm_release_date,
 	CAST(NULL AS STRING) AS cdm_version,
 	CAST(NULL AS integer) AS cdm_version_concept_id,
-	CAST(NULL AS STRING) AS vocabulary_version WHERE 1 = 0;
+	CAST(NULL AS STRING) AS vocabulary_version  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.CONCEPT 
+CREATE TABLE @cdmDatabaseSchema.CONCEPT  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS concept_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS concept_id,
 	CAST(NULL AS STRING) AS concept_name,
 	CAST(NULL AS STRING) AS domain_id,
 	CAST(NULL AS STRING) AS vocabulary_id,
@@ -479,70 +507,78 @@ SELECT 	CAST(NULL AS integer) AS concept_id,
 	CAST(NULL AS STRING) AS concept_code,
 	CAST(NULL AS date) AS valid_start_date,
 	CAST(NULL AS date) AS valid_end_date,
-	CAST(NULL AS STRING) AS invalid_reason WHERE 1 = 0;
+	CAST(NULL AS STRING) AS invalid_reason  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.VOCABULARY 
+CREATE TABLE @cdmDatabaseSchema.VOCABULARY  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS STRING) AS vocabulary_id,
+ AS
+SELECT
+CAST(NULL AS STRING) AS vocabulary_id,
 	CAST(NULL AS STRING) AS vocabulary_name,
 	CAST(NULL AS STRING) AS vocabulary_reference,
 	CAST(NULL AS STRING) AS vocabulary_version,
-	CAST(NULL AS integer) AS vocabulary_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS vocabulary_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.DOMAIN 
+CREATE TABLE @cdmDatabaseSchema.DOMAIN  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS STRING) AS domain_id,
+ AS
+SELECT
+CAST(NULL AS STRING) AS domain_id,
 	CAST(NULL AS STRING) AS domain_name,
-	CAST(NULL AS integer) AS domain_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS domain_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS 
+CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS STRING) AS concept_class_id,
+ AS
+SELECT
+CAST(NULL AS STRING) AS concept_class_id,
 	CAST(NULL AS STRING) AS concept_class_name,
-	CAST(NULL AS integer) AS concept_class_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS concept_class_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP 
+CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS concept_id_1,
+ AS
+SELECT
+CAST(NULL AS integer) AS concept_id_1,
 	CAST(NULL AS integer) AS concept_id_2,
 	CAST(NULL AS STRING) AS relationship_id,
 	CAST(NULL AS date) AS valid_start_date,
 	CAST(NULL AS date) AS valid_end_date,
-	CAST(NULL AS STRING) AS invalid_reason WHERE 1 = 0;
+	CAST(NULL AS STRING) AS invalid_reason  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP 
+CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS STRING) AS relationship_id,
+ AS
+SELECT
+CAST(NULL AS STRING) AS relationship_id,
 	CAST(NULL AS STRING) AS relationship_name,
 	CAST(NULL AS STRING) AS is_hierarchical,
 	CAST(NULL AS STRING) AS defines_ancestry,
 	CAST(NULL AS STRING) AS reverse_relationship_id,
-	CAST(NULL AS integer) AS relationship_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS relationship_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM 
+CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS concept_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS concept_id,
 	CAST(NULL AS STRING) AS concept_synonym_name,
-	CAST(NULL AS integer) AS language_concept_id WHERE 1 = 0;
+	CAST(NULL AS integer) AS language_concept_id  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR 
+CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS ancestor_concept_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS ancestor_concept_id,
 	CAST(NULL AS integer) AS descendant_concept_id,
 	CAST(NULL AS integer) AS min_levels_of_separation,
-	CAST(NULL AS integer) AS max_levels_of_separation WHERE 1 = 0;
+	CAST(NULL AS integer) AS max_levels_of_separation  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP 
+CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS STRING) AS source_code,
+ AS
+SELECT
+CAST(NULL AS STRING) AS source_code,
 	CAST(NULL AS integer) AS source_concept_id,
 	CAST(NULL AS STRING) AS source_vocabulary_id,
 	CAST(NULL AS STRING) AS source_code_description,
@@ -550,12 +586,13 @@ SELECT 	CAST(NULL AS STRING) AS source_code,
 	CAST(NULL AS STRING) AS target_vocabulary_id,
 	CAST(NULL AS date) AS valid_start_date,
 	CAST(NULL AS date) AS valid_end_date,
-	CAST(NULL AS STRING) AS invalid_reason WHERE 1 = 0;
+	CAST(NULL AS STRING) AS invalid_reason  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH 
+CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS drug_concept_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS drug_concept_id,
 	CAST(NULL AS integer) AS ingredient_concept_id,
 	CAST(NULL AS float) AS amount_value,
 	CAST(NULL AS integer) AS amount_unit_concept_id,
@@ -566,23 +603,25 @@ SELECT 	CAST(NULL AS integer) AS drug_concept_id,
 	CAST(NULL AS integer) AS box_size,
 	CAST(NULL AS date) AS valid_start_date,
 	CAST(NULL AS date) AS valid_end_date,
-	CAST(NULL AS STRING) AS invalid_reason WHERE 1 = 0;
+	CAST(NULL AS STRING) AS invalid_reason  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.COHORT 
+CREATE TABLE @cdmDatabaseSchema.COHORT  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS cohort_definition_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS cohort_definition_id,
 	CAST(NULL AS integer) AS subject_id,
 	CAST(NULL AS date) AS cohort_start_date,
-	CAST(NULL AS date) AS cohort_end_date WHERE 1 = 0;
+	CAST(NULL AS date) AS cohort_end_date  WHERE 1 = 0;
 --HINT DISTRIBUTE ON RANDOM
-CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION 
+CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION  
 USING DELTA
-AS
-SELECT 	CAST(NULL AS integer) AS cohort_definition_id,
+ AS
+SELECT
+CAST(NULL AS integer) AS cohort_definition_id,
 	CAST(NULL AS STRING) AS cohort_definition_name,
 	CAST(NULL AS STRING) AS cohort_definition_description,
 	CAST(NULL AS integer) AS definition_type_concept_id,
 	CAST(NULL AS STRING) AS cohort_definition_syntax,
 	CAST(NULL AS integer) AS subject_concept_id,
-	CAST(NULL AS date) AS cohort_initiation_date WHERE 1 = 0;
\ No newline at end of file
+	CAST(NULL AS date) AS cohort_initiation_date  WHERE 1 = 0;
\ No newline at end of file
diff --git a/inst/ddl/5.4/spark/OMOPCDM_spark_5.4_indices.sql b/inst/ddl/5.4/spark/OMOPCDM_spark_5.4_indices.sql
index 578c5b0f..8d4f31be 100644
--- a/inst/ddl/5.4/spark/OMOPCDM_spark_5.4_indices.sql
+++ b/inst/ddl/5.4/spark/OMOPCDM_spark_5.4_indices.sql
@@ -1,70 +1,38 @@
-
 -- spark does not support indexes
-
-
 -- spark does not support indexes
-
 -- spark does not support indexes
 -- spark does not support indexes
-
 -- spark does not support indexes
 -- spark does not support indexes
-
 -- spark does not support indexes
 -- spark does not support indexes
-
 -- spark does not support indexes
 -- spark does not support indexes
-
 -- spark does not support indexes
 -- spark does not support indexes
-
 -- spark does not support indexes
 -- spark does not support indexes
-
 -- spark does not support indexes
 -- spark does not support indexes
-
-
 -- spark does not support indexes
 -- spark does not support indexes
-
 -- spark does not support indexes
-
 -- spark does not support indexes
 -- spark does not support indexes
 -- spark does not support indexes
 -- spark does not support indexes
-
-
-
-
 -- spark does not support indexes
-
 -- spark does not support indexes
-
 -- spark does not support indexes
-
 -- spark does not support indexes
-
-
 -- spark does not support indexes
 -- spark does not support indexes
 -- spark does not support indexes
 -- spark does not support indexes
-
-
-
-
 -- spark does not support indexes
 -- spark does not support indexes
-
-
-
 -- spark does not support indexes
-
 -- spark does not support indexes
 -- spark does not support indexes
 -- spark does not support indexes
-
 -- spark does not support indexes
\ No newline at end of file
diff --git a/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_constraints.sql b/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_constraints.sql
index 2556492a..4bc6bfb1 100644
--- a/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_constraints.sql
+++ b/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_constraints.sql
@@ -1 +1,177 @@
--- azure synapse does not allow Foreign Key Constraints for OMOP Common Data Model 5.4
\ No newline at end of file
+--synapse CDM Foreign Key Constraints for OMOP Common Data Model 5.4
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_concept_id FOREIGN KEY (race_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_concept_id FOREIGN KEY (ethnicity_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_race_source_concept_id FOREIGN KEY (race_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT fpk_PERSON_ethnicity_source_concept_id FOREIGN KEY (ethnicity_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT fpk_OBSERVATION_PERIOD_period_type_concept_id FOREIGN KEY (period_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_concept_id FOREIGN KEY (visit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_type_concept_id FOREIGN KEY (visit_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_visit_source_concept_id FOREIGN KEY (visit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT fpk_VISIT_OCCURRENCE_preceding_visit_occurrence_id FOREIGN KEY (preceding_visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_concept_id FOREIGN KEY (visit_detail_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_type_concept_id FOREIGN KEY (visit_detail_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_detail_source_concept_id FOREIGN KEY (visit_detail_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_admitted_from_concept_id FOREIGN KEY (admitted_from_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_discharged_to_concept_id FOREIGN KEY (discharged_to_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_preceding_visit_detail_id FOREIGN KEY (preceding_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_parent_visit_detail_id FOREIGN KEY (parent_visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT fpk_VISIT_DETAIL_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_type_concept_id FOREIGN KEY (condition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_status_concept_id FOREIGN KEY (condition_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT fpk_CONDITION_OCCURRENCE_condition_source_concept_id FOREIGN KEY (condition_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_type_concept_id FOREIGN KEY (drug_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_route_concept_id FOREIGN KEY (route_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT fpk_DRUG_EXPOSURE_drug_source_concept_id FOREIGN KEY (drug_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_concept_id FOREIGN KEY (procedure_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_type_concept_id FOREIGN KEY (procedure_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_modifier_concept_id FOREIGN KEY (modifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT fpk_PROCEDURE_OCCURRENCE_procedure_source_concept_id FOREIGN KEY (procedure_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_concept_id FOREIGN KEY (device_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_type_concept_id FOREIGN KEY (device_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_device_source_concept_id FOREIGN KEY (device_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT fpk_DEVICE_EXPOSURE_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_concept_id FOREIGN KEY (measurement_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_type_concept_id FOREIGN KEY (measurement_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_operator_concept_id FOREIGN KEY (operator_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_measurement_source_concept_id FOREIGN KEY (measurement_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_unit_source_concept_id FOREIGN KEY (unit_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT fpk_MEASUREMENT_meas_event_field_concept_id FOREIGN KEY (meas_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_concept_id FOREIGN KEY (observation_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_type_concept_id FOREIGN KEY (observation_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_qualifier_concept_id FOREIGN KEY (qualifier_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_observation_source_concept_id FOREIGN KEY (observation_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT fpk_OBSERVATION_obs_event_field_concept_id FOREIGN KEY (obs_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_death_type_concept_id FOREIGN KEY (death_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_concept_id FOREIGN KEY (cause_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DEATH ADD CONSTRAINT fpk_DEATH_cause_source_concept_id FOREIGN KEY (cause_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_type_concept_id FOREIGN KEY (note_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_class_concept_id FOREIGN KEY (note_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_encoding_concept_id FOREIGN KEY (encoding_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_provider_id FOREIGN KEY (provider_id) REFERENCES @cdmDatabaseSchema.PROVIDER (PROVIDER_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_occurrence_id FOREIGN KEY (visit_occurrence_id) REFERENCES @cdmDatabaseSchema.VISIT_OCCURRENCE (VISIT_OCCURRENCE_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_visit_detail_id FOREIGN KEY (visit_detail_id) REFERENCES @cdmDatabaseSchema.VISIT_DETAIL (VISIT_DETAIL_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT fpk_NOTE_note_event_field_concept_id FOREIGN KEY (note_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_section_concept_id FOREIGN KEY (section_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_concept_id FOREIGN KEY (note_nlp_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT fpk_NOTE_NLP_note_nlp_source_concept_id FOREIGN KEY (note_nlp_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_concept_id FOREIGN KEY (specimen_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_specimen_type_concept_id FOREIGN KEY (specimen_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_anatomic_site_concept_id FOREIGN KEY (anatomic_site_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT fpk_SPECIMEN_disease_status_concept_id FOREIGN KEY (disease_status_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_1 FOREIGN KEY (domain_concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_domain_concept_id_2 FOREIGN KEY (domain_concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP ADD CONSTRAINT fpk_FACT_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT fpk_LOCATION_country_concept_id FOREIGN KEY (country_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_place_of_service_concept_id FOREIGN KEY (place_of_service_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT fpk_CARE_SITE_location_id FOREIGN KEY (location_id) REFERENCES @cdmDatabaseSchema.LOCATION (LOCATION_ID);
+ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_concept_id FOREIGN KEY (specialty_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_care_site_id FOREIGN KEY (care_site_id) REFERENCES @cdmDatabaseSchema.CARE_SITE (CARE_SITE_ID);
+ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_concept_id FOREIGN KEY (gender_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_specialty_source_concept_id FOREIGN KEY (specialty_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT fpk_PROVIDER_gender_source_concept_id FOREIGN KEY (gender_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_concept_id FOREIGN KEY (payer_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_payer_source_concept_id FOREIGN KEY (payer_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_concept_id FOREIGN KEY (plan_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_plan_source_concept_id FOREIGN KEY (plan_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_concept_id FOREIGN KEY (sponsor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_sponsor_source_concept_id FOREIGN KEY (sponsor_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_concept_id FOREIGN KEY (stop_reason_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT fpk_PAYER_PLAN_PERIOD_stop_reason_source_concept_id FOREIGN KEY (stop_reason_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_domain_id FOREIGN KEY (cost_domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
+ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_cost_type_concept_id FOREIGN KEY (cost_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_currency_concept_id FOREIGN KEY (currency_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_revenue_code_concept_id FOREIGN KEY (revenue_code_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT fpk_COST_drg_concept_id FOREIGN KEY (drg_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT fpk_DRUG_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT fpk_DOSE_ERA_unit_concept_id FOREIGN KEY (unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT fpk_CONDITION_ERA_condition_concept_id FOREIGN KEY (condition_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_person_id FOREIGN KEY (person_id) REFERENCES @cdmDatabaseSchema.PERSON (PERSON_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_concept_id FOREIGN KEY (episode_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_object_concept_id FOREIGN KEY (episode_object_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_type_concept_id FOREIGN KEY (episode_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT fpk_EPISODE_episode_source_concept_id FOREIGN KEY (episode_source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_id FOREIGN KEY (episode_id) REFERENCES @cdmDatabaseSchema.EPISODE (EPISODE_ID);
+ALTER TABLE @cdmDatabaseSchema.EPISODE_EVENT ADD CONSTRAINT fpk_EPISODE_EVENT_episode_event_field_concept_id FOREIGN KEY (episode_event_field_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_concept_id FOREIGN KEY (metadata_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_metadata_type_concept_id FOREIGN KEY (metadata_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT fpk_METADATA_value_as_concept_id FOREIGN KEY (value_as_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CDM_SOURCE ADD CONSTRAINT fpk_CDM_SOURCE_cdm_version_concept_id FOREIGN KEY (cdm_version_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_domain_id FOREIGN KEY (domain_id) REFERENCES @cdmDatabaseSchema.DOMAIN (DOMAIN_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_vocabulary_id FOREIGN KEY (vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT fpk_CONCEPT_concept_class_id FOREIGN KEY (concept_class_id) REFERENCES @cdmDatabaseSchema.CONCEPT_CLASS (CONCEPT_CLASS_ID);
+ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT fpk_VOCABULARY_vocabulary_concept_id FOREIGN KEY (vocabulary_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT fpk_DOMAIN_domain_concept_id FOREIGN KEY (domain_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT fpk_CONCEPT_CLASS_concept_class_concept_id FOREIGN KEY (concept_class_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_1 FOREIGN KEY (concept_id_1) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_concept_id_2 FOREIGN KEY (concept_id_2) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP ADD CONSTRAINT fpk_CONCEPT_RELATIONSHIP_relationship_id FOREIGN KEY (relationship_id) REFERENCES @cdmDatabaseSchema.RELATIONSHIP (RELATIONSHIP_ID);
+ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT fpk_RELATIONSHIP_relationship_concept_id FOREIGN KEY (relationship_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_concept_id FOREIGN KEY (concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM ADD CONSTRAINT fpk_CONCEPT_SYNONYM_language_concept_id FOREIGN KEY (language_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_ancestor_concept_id FOREIGN KEY (ancestor_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR ADD CONSTRAINT fpk_CONCEPT_ANCESTOR_descendant_concept_id FOREIGN KEY (descendant_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_source_concept_id FOREIGN KEY (source_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_concept_id FOREIGN KEY (target_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP ADD CONSTRAINT fpk_SOURCE_TO_CONCEPT_MAP_target_vocabulary_id FOREIGN KEY (target_vocabulary_id) REFERENCES @cdmDatabaseSchema.VOCABULARY (VOCABULARY_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_drug_concept_id FOREIGN KEY (drug_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_ingredient_concept_id FOREIGN KEY (ingredient_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_amount_unit_concept_id FOREIGN KEY (amount_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_numerator_unit_concept_id FOREIGN KEY (numerator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.DRUG_STRENGTH ADD CONSTRAINT fpk_DRUG_STRENGTH_denominator_unit_concept_id FOREIGN KEY (denominator_unit_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_definition_type_concept_id FOREIGN KEY (definition_type_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
+ALTER TABLE @cdmDatabaseSchema.COHORT_DEFINITION ADD CONSTRAINT fpk_COHORT_DEFINITION_subject_concept_id FOREIGN KEY (subject_concept_id) REFERENCES @cdmDatabaseSchema.CONCEPT (CONCEPT_ID);
diff --git a/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_ddl.sql b/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_ddl.sql
index b6af9623..4ebad946 100644
--- a/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_ddl.sql
+++ b/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_ddl.sql
@@ -1,110 +1,105 @@
--- azure synapse CDM DDL Specification for OMOP Common Data Model 5.4
-
+--synapse CDM DDL Specification for OMOP Common Data Model 5.4
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PERSON (
-                        person_id integer NOT NULL,
-                        gender_concept_id integer NOT NULL,
-                        year_of_birth integer NOT NULL,
-                        month_of_birth integer NULL,
-                        day_of_birth integer NULL,
-                        birth_datetime datetime NULL,
-                        race_concept_id integer NOT NULL,
-                        ethnicity_concept_id integer NOT NULL,
-                        location_id integer NULL,
-                        provider_id integer NULL,
-                        care_site_id integer NULL,
-                        person_source_value varchar(50) NULL,
-                        gender_source_value varchar(50) NULL,
-                        gender_source_concept_id integer NULL,
-                        race_source_value varchar(50) NULL,
-                        race_source_concept_id integer NULL,
-                        ethnicity_source_value varchar(50) NULL,
-                        ethnicity_source_concept_id integer NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			person_id integer NOT NULL,
+			gender_concept_id integer NOT NULL,
+			year_of_birth integer NOT NULL,
+			month_of_birth integer NULL,
+			day_of_birth integer NULL,
+			birth_datetime datetime NULL,
+			race_concept_id integer NOT NULL,
+			ethnicity_concept_id integer NOT NULL,
+			location_id integer NULL,
+			provider_id integer NULL,
+			care_site_id integer NULL,
+			person_source_value varchar(50) NULL,
+			gender_source_value varchar(50) NULL,
+			gender_source_concept_id integer NULL,
+			race_source_value varchar(50) NULL,
+			race_source_concept_id integer NULL,
+			ethnicity_source_value varchar(50) NULL,
+			ethnicity_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD (
-                                    observation_period_id integer NOT NULL,
-                                    person_id integer NOT NULL,
-                                    observation_period_start_date date NOT NULL,
-                                    observation_period_end_date date NOT NULL,
-                                    period_type_concept_id integer NOT NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			observation_period_id integer NOT NULL,
+			person_id integer NOT NULL,
+			observation_period_start_date date NOT NULL,
+			observation_period_end_date date NOT NULL,
+			period_type_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE (
-                                  visit_occurrence_id integer NOT NULL,
-                                  person_id integer NOT NULL,
-                                  visit_concept_id integer NOT NULL,
-                                  visit_start_date date NOT NULL,
-                                  visit_start_datetime datetime NULL,
-                                  visit_end_date date NOT NULL,
-                                  visit_end_datetime datetime NULL,
-                                  visit_type_concept_id Integer NOT NULL,
-                                  provider_id integer NULL,
-                                  care_site_id integer NULL,
-                                  visit_source_value varchar(50) NULL,
-                                  visit_source_concept_id integer NULL,
-                                  admitted_from_concept_id integer NULL,
-                                  admitted_from_source_value varchar(50) NULL,
-                                  discharged_to_concept_id integer NULL,
-                                  discharged_to_source_value varchar(50) NULL,
-                                  preceding_visit_occurrence_id integer NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			visit_occurrence_id integer NOT NULL,
+			person_id integer NOT NULL,
+			visit_concept_id integer NOT NULL,
+			visit_start_date date NOT NULL,
+			visit_start_datetime datetime NULL,
+			visit_end_date date NOT NULL,
+			visit_end_datetime datetime NULL,
+			visit_type_concept_id Integer NOT NULL,
+			provider_id integer NULL,
+			care_site_id integer NULL,
+			visit_source_value varchar(50) NULL,
+			visit_source_concept_id integer NULL,
+			admitted_from_concept_id integer NULL,
+			admitted_from_source_value varchar(50) NULL,
+			discharged_to_concept_id integer NULL,
+			discharged_to_source_value varchar(50) NULL,
+			preceding_visit_occurrence_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.VISIT_DETAIL (
-                              visit_detail_id integer NOT NULL,
-                              person_id integer NOT NULL,
-                              visit_detail_concept_id integer NOT NULL,
-                              visit_detail_start_date date NOT NULL,
-                              visit_detail_start_datetime datetime NULL,
-                              visit_detail_end_date date NOT NULL,
-                              visit_detail_end_datetime datetime NULL,
-                              visit_detail_type_concept_id integer NOT NULL,
-                              provider_id integer NULL,
-                              care_site_id integer NULL,
-                              visit_detail_source_value varchar(50) NULL,
-                              visit_detail_source_concept_id Integer NULL,
-                              admitted_from_concept_id Integer NULL,
-                              admitted_from_source_value varchar(50) NULL,
-                              discharged_to_source_value varchar(50) NULL,
-                              discharged_to_concept_id integer NULL,
-                              preceding_visit_detail_id integer NULL,
-                              parent_visit_detail_id integer NULL,
-                              visit_occurrence_id integer NOT NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			visit_detail_id integer NOT NULL,
+			person_id integer NOT NULL,
+			visit_detail_concept_id integer NOT NULL,
+			visit_detail_start_date date NOT NULL,
+			visit_detail_start_datetime datetime NULL,
+			visit_detail_end_date date NOT NULL,
+			visit_detail_end_datetime datetime NULL,
+			visit_detail_type_concept_id integer NOT NULL,
+			provider_id integer NULL,
+			care_site_id integer NULL,
+			visit_detail_source_value varchar(50) NULL,
+			visit_detail_source_concept_id Integer NULL,
+			admitted_from_concept_id Integer NULL,
+			admitted_from_source_value varchar(50) NULL,
+			discharged_to_source_value varchar(50) NULL,
+			discharged_to_concept_id integer NULL,
+			preceding_visit_detail_id integer NULL,
+			parent_visit_detail_id integer NULL,
+			visit_occurrence_id integer NOT NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE (
-                                      condition_occurrence_id integer NOT NULL,
-                                      person_id integer NOT NULL,
-                                      condition_concept_id integer NOT NULL,
-                                      condition_start_date date NOT NULL,
-                                      condition_start_datetime datetime NULL,
-                                      condition_end_date date NULL,
-                                      condition_end_datetime datetime NULL,
-                                      condition_type_concept_id integer NOT NULL,
-                                      condition_status_concept_id integer NULL,
-                                      stop_reason varchar(20) NULL,
-                                      provider_id integer NULL,
-                                      visit_occurrence_id integer NULL,
-                                      visit_detail_id integer NULL,
-                                      condition_source_value varchar(50) NULL,
-                                      condition_source_concept_id integer NULL,
-                                      condition_status_source_value varchar(50) NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			condition_occurrence_id integer NOT NULL,
+			person_id integer NOT NULL,
+			condition_concept_id integer NOT NULL,
+			condition_start_date date NOT NULL,
+			condition_start_datetime datetime NULL,
+			condition_end_date date NULL,
+			condition_end_datetime datetime NULL,
+			condition_type_concept_id integer NOT NULL,
+			condition_status_concept_id integer NULL,
+			stop_reason varchar(20) NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			condition_source_value varchar(50) NULL,
+			condition_source_concept_id integer NULL,
+			condition_status_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
-                               drug_exposure_id integer NOT NULL,
-                               person_id integer NOT NULL,
-                               drug_concept_id integer NOT NULL,
-                               drug_exposure_start_date date NOT NULL,
-                               drug_exposure_start_datetime datetime NULL,
-                               drug_exposure_end_date date NOT NULL,
-                               drug_exposure_end_datetime datetime NULL,
-                               verbatim_end_date date NULL,
-                               drug_type_concept_id integer NOT NULL,
-                               stop_reason varchar(20) NULL,
-                               refills integer NULL,
-                               quantity float NULL,
-                               days_supply integer NULL,
-                               sig varchar(MAX) NULL,
+			drug_exposure_id integer NOT NULL,
+			person_id integer NOT NULL,
+			drug_concept_id integer NOT NULL,
+			drug_exposure_start_date date NOT NULL,
+			drug_exposure_start_datetime datetime NULL,
+			drug_exposure_end_date date NOT NULL,
+			drug_exposure_end_datetime datetime NULL,
+			verbatim_end_date date NULL,
+			drug_type_concept_id integer NOT NULL,
+			stop_reason varchar(20) NULL,
+			refills integer NULL,
+			quantity float NULL,
+			days_supply integer NULL,
+			sig VARCHAR(8000) NULL,
 			route_concept_id integer NULL,
 			lot_number varchar(50) NULL,
 			provider_id integer NULL,
@@ -113,119 +108,113 @@ CREATE TABLE @cdmDatabaseSchema.DRUG_EXPOSURE (
 			drug_source_value varchar(50) NULL,
 			drug_source_concept_id integer NULL,
 			route_source_value varchar(50) NULL,
-			dose_unit_source_value varchar(50) NULL )
-		 WITH (CLUSTERED INDEX(person_id));
-
+			dose_unit_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE (
-                                      procedure_occurrence_id integer NOT NULL,
-                                      person_id integer NOT NULL,
-                                      procedure_concept_id integer NOT NULL,
-                                      procedure_date date NOT NULL,
-                                      procedure_datetime datetime NULL,
-                                      procedure_end_date date NULL,
-                                      procedure_end_datetime datetime NULL,
-                                      procedure_type_concept_id integer NOT NULL,
-                                      modifier_concept_id integer NULL,
-                                      quantity integer NULL,
-                                      provider_id integer NULL,
-                                      visit_occurrence_id integer NULL,
-                                      visit_detail_id integer NULL,
-                                      procedure_source_value varchar(50) NULL,
-                                      procedure_source_concept_id integer NULL,
-                                      modifier_source_value varchar(50) NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			procedure_occurrence_id integer NOT NULL,
+			person_id integer NOT NULL,
+			procedure_concept_id integer NOT NULL,
+			procedure_date date NOT NULL,
+			procedure_datetime datetime NULL,
+			procedure_end_date date NULL,
+			procedure_end_datetime datetime NULL,
+			procedure_type_concept_id integer NOT NULL,
+			modifier_concept_id integer NULL,
+			quantity integer NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			procedure_source_value varchar(50) NULL,
+			procedure_source_concept_id integer NULL,
+			modifier_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE (
-                                 device_exposure_id integer NOT NULL,
-                                 person_id integer NOT NULL,
-                                 device_concept_id integer NOT NULL,
-                                 device_exposure_start_date date NOT NULL,
-                                 device_exposure_start_datetime datetime NULL,
-                                 device_exposure_end_date date NULL,
-                                 device_exposure_end_datetime datetime NULL,
-                                 device_type_concept_id integer NOT NULL,
-                                 unique_device_id varchar(255) NULL,
-                                 production_id varchar(255) NULL,
-                                 quantity integer NULL,
-                                 provider_id integer NULL,
-                                 visit_occurrence_id integer NULL,
-                                 visit_detail_id integer NULL,
-                                 device_source_value varchar(50) NULL,
-                                 device_source_concept_id integer NULL,
-                                 unit_concept_id integer NULL,
-                                 unit_source_value varchar(50) NULL,
-                                 unit_source_concept_id integer NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			device_exposure_id integer NOT NULL,
+			person_id integer NOT NULL,
+			device_concept_id integer NOT NULL,
+			device_exposure_start_date date NOT NULL,
+			device_exposure_start_datetime datetime NULL,
+			device_exposure_end_date date NULL,
+			device_exposure_end_datetime datetime NULL,
+			device_type_concept_id integer NOT NULL,
+			unique_device_id varchar(255) NULL,
+			production_id varchar(255) NULL,
+			quantity integer NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			device_source_value varchar(50) NULL,
+			device_source_concept_id integer NULL,
+			unit_concept_id integer NULL,
+			unit_source_value varchar(50) NULL,
+			unit_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.MEASUREMENT (
-                             measurement_id integer NOT NULL,
-                             person_id integer NOT NULL,
-                             measurement_concept_id integer NOT NULL,
-                             measurement_date date NOT NULL,
-                             measurement_datetime datetime NULL,
-                             measurement_time varchar(10) NULL,
-                             measurement_type_concept_id integer NOT NULL,
-                             operator_concept_id integer NULL,
-                             value_as_number float NULL,
-                             value_as_concept_id integer NULL,
-                             unit_concept_id integer NULL,
-                             range_low float NULL,
-                             range_high float NULL,
-                             provider_id integer NULL,
-                             visit_occurrence_id integer NULL,
-                             visit_detail_id integer NULL,
-                             measurement_source_value varchar(50) NULL,
-                             measurement_source_concept_id integer NULL,
-                             unit_source_value varchar(50) NULL,
-                             unit_source_concept_id integer NULL,
-                             value_source_value varchar(50) NULL,
-                             measurement_event_id integer NULL,
-                             meas_event_field_concept_id integer NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			measurement_id integer NOT NULL,
+			person_id integer NOT NULL,
+			measurement_concept_id integer NOT NULL,
+			measurement_date date NOT NULL,
+			measurement_datetime datetime NULL,
+			measurement_time varchar(10) NULL,
+			measurement_type_concept_id integer NOT NULL,
+			operator_concept_id integer NULL,
+			value_as_number float NULL,
+			value_as_concept_id integer NULL,
+			unit_concept_id integer NULL,
+			range_low float NULL,
+			range_high float NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			measurement_source_value varchar(50) NULL,
+			measurement_source_concept_id integer NULL,
+			unit_source_value varchar(50) NULL,
+			unit_source_concept_id integer NULL,
+			value_source_value varchar(50) NULL,
+			measurement_event_id integer NULL,
+			meas_event_field_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.OBSERVATION (
-                             observation_id integer NOT NULL,
-                             person_id integer NOT NULL,
-                             observation_concept_id integer NOT NULL,
-                             observation_date date NOT NULL,
-                             observation_datetime datetime NULL,
-                             observation_type_concept_id integer NOT NULL,
-                             value_as_number float NULL,
-                             value_as_string varchar(60) NULL,
-                             value_as_concept_id Integer NULL,
-                             qualifier_concept_id integer NULL,
-                             unit_concept_id integer NULL,
-                             provider_id integer NULL,
-                             visit_occurrence_id integer NULL,
-                             visit_detail_id integer NULL,
-                             observation_source_value varchar(50) NULL,
-                             observation_source_concept_id integer NULL,
-                             unit_source_value varchar(50) NULL,
-                             qualifier_source_value varchar(50) NULL,
-                             value_source_value varchar(50) NULL,
-                             observation_event_id integer NULL,
-                             obs_event_field_concept_id integer NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			observation_id integer NOT NULL,
+			person_id integer NOT NULL,
+			observation_concept_id integer NOT NULL,
+			observation_date date NOT NULL,
+			observation_datetime datetime NULL,
+			observation_type_concept_id integer NOT NULL,
+			value_as_number float NULL,
+			value_as_string varchar(60) NULL,
+			value_as_concept_id Integer NULL,
+			qualifier_concept_id integer NULL,
+			unit_concept_id integer NULL,
+			provider_id integer NULL,
+			visit_occurrence_id integer NULL,
+			visit_detail_id integer NULL,
+			observation_source_value varchar(50) NULL,
+			observation_source_concept_id integer NULL,
+			unit_source_value varchar(50) NULL,
+			qualifier_source_value varchar(50) NULL,
+			value_source_value varchar(50) NULL,
+			observation_event_id integer NULL,
+			obs_event_field_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DEATH (
-                       person_id integer NOT NULL,
-                       death_date date NOT NULL,
-                       death_datetime datetime NULL,
-                       death_type_concept_id integer NULL,
-                       cause_concept_id integer NULL,
-                       cause_source_value varchar(50) NULL,
-                       cause_source_concept_id integer NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			person_id integer NOT NULL,
+			death_date date NOT NULL,
+			death_datetime datetime NULL,
+			death_type_concept_id integer NULL,
+			cause_concept_id integer NULL,
+			cause_source_value varchar(50) NULL,
+			cause_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.NOTE (
-                      note_id integer NOT NULL,
-                      person_id integer NOT NULL,
-                      note_date date NOT NULL,
-                      note_datetime datetime NULL,
-                      note_type_concept_id integer NOT NULL,
-                      note_class_concept_id integer NOT NULL,
-                      note_title varchar(250) NULL,
-                      note_text varchar(MAX) NOT NULL,
+			note_id integer NOT NULL,
+			person_id integer NOT NULL,
+			note_date date NOT NULL,
+			note_datetime datetime NULL,
+			note_type_concept_id integer NOT NULL,
+			note_class_concept_id integer NOT NULL,
+			note_title varchar(250) NULL,
+			note_text VARCHAR(8000) NOT NULL,
 			encoding_concept_id integer NOT NULL,
 			language_concept_id integer NOT NULL,
 			provider_id integer NULL,
@@ -233,314 +222,290 @@ CREATE TABLE @cdmDatabaseSchema.NOTE (
 			visit_detail_id integer NULL,
 			note_source_value varchar(50) NULL,
 			note_event_id integer NULL,
-			note_event_field_concept_id integer NULL )
-		 WITH (CLUSTERED INDEX(person_id));
-
+			note_event_field_concept_id integer NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.NOTE_NLP (
-                          note_nlp_id integer NOT NULL,
-                          note_id integer NOT NULL,
-                          section_concept_id integer NULL,
-                          snippet varchar(250) NULL,
-                          "offset" varchar(50) NULL,
-                          lexical_variant varchar(250) NOT NULL,
-                          note_nlp_concept_id integer NULL,
-                          note_nlp_source_concept_id integer NULL,
-                          nlp_system varchar(250) NULL,
-                          nlp_date date NOT NULL,
-                          nlp_datetime datetime NULL,
-                          term_exists varchar(1) NULL,
-                          term_temporal varchar(50) NULL,
-                          term_modifiers varchar(2000) NULL )
-    WITH (CLUSTERED INDEX(note_id));
-
+			note_nlp_id integer NOT NULL,
+			note_id integer NOT NULL,
+			section_concept_id integer NULL,
+			snippet varchar(250) NULL,
+			"offset" varchar(50) NULL,
+			lexical_variant varchar(250) NOT NULL,
+			note_nlp_concept_id integer NULL,
+			note_nlp_source_concept_id integer NULL,
+			nlp_system varchar(250) NULL,
+			nlp_date date NOT NULL,
+			nlp_datetime datetime NULL,
+			term_exists varchar(1) NULL,
+			term_temporal varchar(50) NULL,
+			term_modifiers varchar(2000) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.SPECIMEN (
-                          specimen_id integer NOT NULL,
-                          person_id integer NOT NULL,
-                          specimen_concept_id integer NOT NULL,
-                          specimen_type_concept_id integer NOT NULL,
-                          specimen_date date NOT NULL,
-                          specimen_datetime datetime NULL,
-                          quantity float NULL,
-                          unit_concept_id integer NULL,
-                          anatomic_site_concept_id integer NULL,
-                          disease_status_concept_id integer NULL,
-                          specimen_source_id varchar(50) NULL,
-                          specimen_source_value varchar(50) NULL,
-                          unit_source_value varchar(50) NULL,
-                          anatomic_site_source_value varchar(50) NULL,
-                          disease_status_source_value varchar(50) NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			specimen_id integer NOT NULL,
+			person_id integer NOT NULL,
+			specimen_concept_id integer NOT NULL,
+			specimen_type_concept_id integer NOT NULL,
+			specimen_date date NOT NULL,
+			specimen_datetime datetime NULL,
+			quantity float NULL,
+			unit_concept_id integer NULL,
+			anatomic_site_concept_id integer NULL,
+			disease_status_concept_id integer NULL,
+			specimen_source_id varchar(50) NULL,
+			specimen_source_value varchar(50) NULL,
+			unit_source_value varchar(50) NULL,
+			anatomic_site_source_value varchar(50) NULL,
+			disease_status_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.FACT_RELATIONSHIP (
-                                   domain_concept_id_1 integer NOT NULL,
-                                   fact_id_1 integer NOT NULL,
-                                   domain_concept_id_2 integer NOT NULL,
-                                   fact_id_2 integer NOT NULL,
-                                   relationship_concept_id integer NOT NULL );
-
+			domain_concept_id_1 integer NOT NULL,
+			fact_id_1 integer NOT NULL,
+			domain_concept_id_2 integer NOT NULL,
+			fact_id_2 integer NOT NULL,
+			relationship_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.LOCATION (
-                          location_id integer NOT NULL,
-                          address_1 varchar(50) NULL,
-                          address_2 varchar(50) NULL,
-                          city varchar(50) NULL,
-                          state varchar(2) NULL,
-                          zip varchar(9) NULL,
-                          county varchar(20) NULL,
-                          location_source_value varchar(50) NULL,
-                          country_concept_id integer NULL,
-                          country_source_value varchar(80) NULL,
-                          latitude float NULL,
-                          longitude float NULL )
-    WITH (CLUSTERED INDEX(location_id));
-
+			location_id integer NOT NULL,
+			address_1 varchar(50) NULL,
+			address_2 varchar(50) NULL,
+			city varchar(50) NULL,
+			state varchar(2) NULL,
+			zip varchar(9) NULL,
+			county varchar(20) NULL,
+			location_source_value varchar(50) NULL,
+			country_concept_id integer NULL,
+			country_source_value varchar(80) NULL,
+			latitude float NULL,
+			longitude float NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CARE_SITE (
-                           care_site_id integer NOT NULL,
-                           care_site_name varchar(255) NULL,
-                           place_of_service_concept_id integer NULL,
-                           location_id integer NULL,
-                           care_site_source_value varchar(50) NULL,
-                           place_of_service_source_value varchar(50) NULL )
-    WITH (CLUSTERED INDEX(care_site_id));
-
+			care_site_id integer NOT NULL,
+			care_site_name varchar(255) NULL,
+			place_of_service_concept_id integer NULL,
+			location_id integer NULL,
+			care_site_source_value varchar(50) NULL,
+			place_of_service_source_value varchar(50) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.PROVIDER (
-                          provider_id integer NOT NULL,
-                          provider_name varchar(255) NULL,
-                          npi varchar(20) NULL,
-                          dea varchar(20) NULL,
-                          specialty_concept_id integer NULL,
-                          care_site_id integer NULL,
-                          year_of_birth integer NULL,
-                          gender_concept_id integer NULL,
-                          provider_source_value varchar(50) NULL,
-                          specialty_source_value varchar(50) NULL,
-                          specialty_source_concept_id integer NULL,
-                          gender_source_value varchar(50) NULL,
-                          gender_source_concept_id integer NULL )
-    WITH (CLUSTERED INDEX(provider_id));
-
+			provider_id integer NOT NULL,
+			provider_name varchar(255) NULL,
+			npi varchar(20) NULL,
+			dea varchar(20) NULL,
+			specialty_concept_id integer NULL,
+			care_site_id integer NULL,
+			year_of_birth integer NULL,
+			gender_concept_id integer NULL,
+			provider_source_value varchar(50) NULL,
+			specialty_source_value varchar(50) NULL,
+			specialty_source_concept_id integer NULL,
+			gender_source_value varchar(50) NULL,
+			gender_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD (
-                                   payer_plan_period_id integer NOT NULL,
-                                   person_id integer NOT NULL,
-                                   payer_plan_period_start_date date NOT NULL,
-                                   payer_plan_period_end_date date NOT NULL,
-                                   payer_concept_id integer NULL,
-                                   payer_source_value varchar(50) NULL,
-                                   payer_source_concept_id integer NULL,
-                                   plan_concept_id integer NULL,
-                                   plan_source_value varchar(50) NULL,
-                                   plan_source_concept_id integer NULL,
-                                   sponsor_concept_id integer NULL,
-                                   sponsor_source_value varchar(50) NULL,
-                                   sponsor_source_concept_id integer NULL,
-                                   family_source_value varchar(50) NULL,
-                                   stop_reason_concept_id integer NULL,
-                                   stop_reason_source_value varchar(50) NULL,
-                                   stop_reason_source_concept_id integer NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			payer_plan_period_id integer NOT NULL,
+			person_id integer NOT NULL,
+			payer_plan_period_start_date date NOT NULL,
+			payer_plan_period_end_date date NOT NULL,
+			payer_concept_id integer NULL,
+			payer_source_value varchar(50) NULL,
+			payer_source_concept_id integer NULL,
+			plan_concept_id integer NULL,
+			plan_source_value varchar(50) NULL,
+			plan_source_concept_id integer NULL,
+			sponsor_concept_id integer NULL,
+			sponsor_source_value varchar(50) NULL,
+			sponsor_source_concept_id integer NULL,
+			family_source_value varchar(50) NULL,
+			stop_reason_concept_id integer NULL,
+			stop_reason_source_value varchar(50) NULL,
+			stop_reason_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COST (
-                      cost_id integer NOT NULL,
-                      cost_event_id integer NOT NULL,
-                      cost_domain_id varchar(20) NOT NULL,
-                      cost_type_concept_id integer NOT NULL,
-                      currency_concept_id integer NULL,
-                      total_charge float NULL,
-                      total_cost float NULL,
-                      total_paid float NULL,
-                      paid_by_payer float NULL,
-                      paid_by_patient float NULL,
-                      paid_patient_copay float NULL,
-                      paid_patient_coinsurance float NULL,
-                      paid_patient_deductible float NULL,
-                      paid_by_primary float NULL,
-                      paid_ingredient_cost float NULL,
-                      paid_dispensing_fee float NULL,
-                      payer_plan_period_id integer NULL,
-                      amount_allowed float NULL,
-                      revenue_code_concept_id integer NULL,
-                      revenue_code_source_value varchar(50) NULL,
-                      drg_concept_id integer NULL,
-                      drg_source_value varchar(3) NULL );
-
+			cost_id integer NOT NULL,
+			cost_event_id integer NOT NULL,
+			cost_domain_id varchar(20) NOT NULL,
+			cost_type_concept_id integer NOT NULL,
+			currency_concept_id integer NULL,
+			total_charge float NULL,
+			total_cost float NULL,
+			total_paid float NULL,
+			paid_by_payer float NULL,
+			paid_by_patient float NULL,
+			paid_patient_copay float NULL,
+			paid_patient_coinsurance float NULL,
+			paid_patient_deductible float NULL,
+			paid_by_primary float NULL,
+			paid_ingredient_cost float NULL,
+			paid_dispensing_fee float NULL,
+			payer_plan_period_id integer NULL,
+			amount_allowed float NULL,
+			revenue_code_concept_id integer NULL,
+			revenue_code_source_value varchar(50) NULL,
+			drg_concept_id integer NULL,
+			drg_source_value varchar(3) NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DRUG_ERA (
-                          drug_era_id integer NOT NULL,
-                          person_id integer NOT NULL,
-                          drug_concept_id integer NOT NULL,
-                          drug_era_start_date date NOT NULL,
-                          drug_era_end_date date NOT NULL,
-                          drug_exposure_count integer NULL,
-                          gap_days integer NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			drug_era_id integer NOT NULL,
+			person_id integer NOT NULL,
+			drug_concept_id integer NOT NULL,
+			drug_era_start_date date NOT NULL,
+			drug_era_end_date date NOT NULL,
+			drug_exposure_count integer NULL,
+			gap_days integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.DOSE_ERA (
-                          dose_era_id integer NOT NULL,
-                          person_id integer NOT NULL,
-                          drug_concept_id integer NOT NULL,
-                          unit_concept_id integer NOT NULL,
-                          dose_value float NOT NULL,
-                          dose_era_start_date date NOT NULL,
-                          dose_era_end_date date NOT NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			dose_era_id integer NOT NULL,
+			person_id integer NOT NULL,
+			drug_concept_id integer NOT NULL,
+			unit_concept_id integer NOT NULL,
+			dose_value float NOT NULL,
+			dose_era_start_date date NOT NULL,
+			dose_era_end_date date NOT NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.CONDITION_ERA (
-                               condition_era_id integer NOT NULL,
-                               person_id integer NOT NULL,
-                               condition_concept_id integer NOT NULL,
-                               condition_era_start_date date NOT NULL,
-                               condition_era_end_date date NOT NULL,
-                               condition_occurrence_count integer NULL )
-    WITH (CLUSTERED INDEX(person_id));
-
+			condition_era_id integer NOT NULL,
+			person_id integer NOT NULL,
+			condition_concept_id integer NOT NULL,
+			condition_era_start_date date NOT NULL,
+			condition_era_end_date date NOT NULL,
+			condition_occurrence_count integer NULL );
+--HINT DISTRIBUTE ON KEY (person_id)
 CREATE TABLE @cdmDatabaseSchema.EPISODE (
-                         episode_id integer NOT NULL,
-                         person_id integer NOT NULL,
-                         episode_concept_id integer NOT NULL,
-                         episode_start_date date NOT NULL,
-                         episode_start_datetime datetime NULL,
-                         episode_end_date date NULL,
-                         episode_end_datetime datetime NULL,
-                         episode_parent_id integer NULL,
-                         episode_number integer NULL,
-                         episode_object_concept_id integer NOT NULL,
-                         episode_type_concept_id integer NOT NULL,
-                         episode_source_value varchar(50) NULL,
-                         episode_source_concept_id integer NULL );
-
+			episode_id integer NOT NULL,
+			person_id integer NOT NULL,
+			episode_concept_id integer NOT NULL,
+			episode_start_date date NOT NULL,
+			episode_start_datetime datetime NULL,
+			episode_end_date date NULL,
+			episode_end_datetime datetime NULL,
+			episode_parent_id integer NULL,
+			episode_number integer NULL,
+			episode_object_concept_id integer NOT NULL,
+			episode_type_concept_id integer NOT NULL,
+			episode_source_value varchar(50) NULL,
+			episode_source_concept_id integer NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.EPISODE_EVENT (
-                               episode_id integer NOT NULL,
-                               event_id integer NOT NULL,
-                               episode_event_field_concept_id integer NOT NULL );
-
+			episode_id integer NOT NULL,
+			event_id integer NOT NULL,
+			episode_event_field_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.METADATA (
-                          metadata_id integer NOT NULL,
-                          metadata_concept_id integer NOT NULL,
-                          metadata_type_concept_id integer NOT NULL,
-                          name varchar(250) NOT NULL,
-                          value_as_string varchar(250) NULL,
-                          value_as_concept_id integer NULL,
-                          value_as_number float NULL,
-                          metadata_date date NULL,
-                          metadata_datetime datetime NULL )
-    WITH (CLUSTERED INDEX(metadata_concept_id));
-
+			metadata_id integer NOT NULL,
+			metadata_concept_id integer NOT NULL,
+			metadata_type_concept_id integer NOT NULL,
+			name varchar(250) NOT NULL,
+			value_as_string varchar(250) NULL,
+			value_as_concept_id integer NULL,
+			value_as_number float NULL,
+			metadata_date date NULL,
+			metadata_datetime datetime NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CDM_SOURCE (
-                            cdm_source_name varchar(255) NOT NULL,
-                            cdm_source_abbreviation varchar(25) NOT NULL,
-                            cdm_holder varchar(255) NOT NULL,
-                            source_description varchar(MAX) NULL,
+			cdm_source_name varchar(255) NOT NULL,
+			cdm_source_abbreviation varchar(25) NOT NULL,
+			cdm_holder varchar(255) NOT NULL,
+			source_description VARCHAR(8000) NULL,
 			source_documentation_reference varchar(255) NULL,
 			cdm_etl_reference varchar(255) NULL,
 			source_release_date date NOT NULL,
 			cdm_release_date date NOT NULL,
 			cdm_version varchar(10) NULL,
 			cdm_version_concept_id integer NOT NULL,
-			vocabulary_version varchar(20) NOT NULL )
-		 WITH (CLUSTERED INDEX(cdm_version_concept_id));
-
+			vocabulary_version varchar(20) NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT (
-                         concept_id integer NOT NULL,
-                         concept_name varchar(255) NOT NULL,
-                         domain_id varchar(20) NOT NULL,
-                         vocabulary_id varchar(20) NOT NULL,
-                         concept_class_id varchar(20) NOT NULL,
-                         standard_concept varchar(1) NULL,
-                         concept_code varchar(50) NOT NULL,
-                         valid_start_date date NOT NULL,
-                         valid_end_date date NOT NULL,
-                         invalid_reason varchar(1) NULL )
-    WITH (CLUSTERED INDEX(concept_id));
-
+			concept_id integer NOT NULL,
+			concept_name varchar(255) NOT NULL,
+			domain_id varchar(20) NOT NULL,
+			vocabulary_id varchar(20) NOT NULL,
+			concept_class_id varchar(20) NOT NULL,
+			standard_concept varchar(1) NULL,
+			concept_code varchar(50) NOT NULL,
+			valid_start_date date NOT NULL,
+			valid_end_date date NOT NULL,
+			invalid_reason varchar(1) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.VOCABULARY (
-                            vocabulary_id varchar(20) NOT NULL,
-                            vocabulary_name varchar(255) NOT NULL,
-                            vocabulary_reference varchar(255) NULL,
-                            vocabulary_version varchar(255) NULL,
-                            vocabulary_concept_id integer NOT NULL )
-    WITH (CLUSTERED INDEX(vocabulary_id));
-
+			vocabulary_id varchar(20) NOT NULL,
+			vocabulary_name varchar(255) NOT NULL,
+			vocabulary_reference varchar(255) NULL,
+			vocabulary_version varchar(255) NULL,
+			vocabulary_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DOMAIN (
-                        domain_id varchar(20) NOT NULL,
-                        domain_name varchar(255) NOT NULL,
-                        domain_concept_id integer NOT NULL )
-    WITH (CLUSTERED INDEX(domain_id));
-
+			domain_id varchar(20) NOT NULL,
+			domain_name varchar(255) NOT NULL,
+			domain_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_CLASS (
-                               concept_class_id varchar(20) NOT NULL,
-                               concept_class_name varchar(255) NOT NULL,
-                               concept_class_concept_id integer NOT NULL )
-    WITH (CLUSTERED INDEX(concept_class_id));
-
+			concept_class_id varchar(20) NOT NULL,
+			concept_class_name varchar(255) NOT NULL,
+			concept_class_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_RELATIONSHIP (
-                                      concept_id_1 integer NOT NULL,
-                                      concept_id_2 integer NOT NULL,
-                                      relationship_id varchar(20) NOT NULL,
-                                      valid_start_date date NOT NULL,
-                                      valid_end_date date NOT NULL,
-                                      invalid_reason varchar(1) NULL )
-    WITH (CLUSTERED INDEX(concept_id_1));
-
+			concept_id_1 integer NOT NULL,
+			concept_id_2 integer NOT NULL,
+			relationship_id varchar(20) NOT NULL,
+			valid_start_date date NOT NULL,
+			valid_end_date date NOT NULL,
+			invalid_reason varchar(1) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.RELATIONSHIP (
-                              relationship_id varchar(20) NOT NULL,
-                              relationship_name varchar(255) NOT NULL,
-                              is_hierarchical varchar(1) NOT NULL,
-                              defines_ancestry varchar(1) NOT NULL,
-                              reverse_relationship_id varchar(20) NOT NULL,
-                              relationship_concept_id integer NOT NULL )
-    WITH (CLUSTERED INDEX(relationship_id));
-
+			relationship_id varchar(20) NOT NULL,
+			relationship_name varchar(255) NOT NULL,
+			is_hierarchical varchar(1) NOT NULL,
+			defines_ancestry varchar(1) NOT NULL,
+			reverse_relationship_id varchar(20) NOT NULL,
+			relationship_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_SYNONYM (
-                                 concept_id integer NOT NULL,
-                                 concept_synonym_name varchar(1000) NOT NULL,
-                                 language_concept_id integer NOT NULL )
-    WITH (CLUSTERED INDEX(concept_id));
-
+			concept_id integer NOT NULL,
+			concept_synonym_name varchar(1000) NOT NULL,
+			language_concept_id integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.CONCEPT_ANCESTOR (
-                                  ancestor_concept_id integer NOT NULL,
-                                  descendant_concept_id integer NOT NULL,
-                                  min_levels_of_separation integer NOT NULL,
-                                  max_levels_of_separation integer NOT NULL )
-    WITH (CLUSTERED INDEX(ancestor_concept_id));
-
+			ancestor_concept_id integer NOT NULL,
+			descendant_concept_id integer NOT NULL,
+			min_levels_of_separation integer NOT NULL,
+			max_levels_of_separation integer NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.SOURCE_TO_CONCEPT_MAP (
-                                       source_code varchar(50) NOT NULL,
-                                       source_concept_id integer NOT NULL,
-                                       source_vocabulary_id varchar(20) NOT NULL,
-                                       source_code_description varchar(255) NULL,
-                                       target_concept_id integer NOT NULL,
-                                       target_vocabulary_id varchar(20) NOT NULL,
-                                       valid_start_date date NOT NULL,
-                                       valid_end_date date NOT NULL,
-                                       invalid_reason varchar(1) NULL )
-    WITH (CLUSTERED INDEX(target_concept_id));
-
+			source_code varchar(50) NOT NULL,
+			source_concept_id integer NOT NULL,
+			source_vocabulary_id varchar(20) NOT NULL,
+			source_code_description varchar(255) NULL,
+			target_concept_id integer NOT NULL,
+			target_vocabulary_id varchar(20) NOT NULL,
+			valid_start_date date NOT NULL,
+			valid_end_date date NOT NULL,
+			invalid_reason varchar(1) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.DRUG_STRENGTH (
-                               drug_concept_id integer NOT NULL,
-                               ingredient_concept_id integer NOT NULL,
-                               amount_value float NULL,
-                               amount_unit_concept_id integer NULL,
-                               numerator_value float NULL,
-                               numerator_unit_concept_id integer NULL,
-                               denominator_value float NULL,
-                               denominator_unit_concept_id integer NULL,
-                               box_size integer NULL,
-                               valid_start_date date NOT NULL,
-                               valid_end_date date NOT NULL,
-                               invalid_reason varchar(1) NULL )
-    WITH (CLUSTERED INDEX(drug_concept_id));
-
+			drug_concept_id integer NOT NULL,
+			ingredient_concept_id integer NOT NULL,
+			amount_value float NULL,
+			amount_unit_concept_id integer NULL,
+			numerator_value float NULL,
+			numerator_unit_concept_id integer NULL,
+			denominator_value float NULL,
+			denominator_unit_concept_id integer NULL,
+			box_size integer NULL,
+			valid_start_date date NOT NULL,
+			valid_end_date date NOT NULL,
+			invalid_reason varchar(1) NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT (
-                        cohort_definition_id integer NOT NULL,
-                        subject_id integer NOT NULL,
-                        cohort_start_date date NOT NULL,
-                        cohort_end_date date NOT NULL )
-    WITH (CLUSTERED INDEX(cohort_definition_id));
-
+			cohort_definition_id integer NOT NULL,
+			subject_id integer NOT NULL,
+			cohort_start_date date NOT NULL,
+			cohort_end_date date NOT NULL );
+--HINT DISTRIBUTE ON RANDOM
 CREATE TABLE @cdmDatabaseSchema.COHORT_DEFINITION (
-                                   cohort_definition_id integer NOT NULL,
-                                   cohort_definition_name varchar(255) NOT NULL,
-                                   cohort_definition_description varchar(MAX) NULL,
+			cohort_definition_id integer NOT NULL,
+			cohort_definition_name varchar(255) NOT NULL,
+			cohort_definition_description VARCHAR(8000) NULL,
 			definition_type_concept_id integer NOT NULL,
-			cohort_definition_syntax varchar(MAX) NULL,
+			cohort_definition_syntax VARCHAR(8000) NULL,
 			subject_concept_id integer NOT NULL,
-			cohort_initiation_date date NULL )
-		 WITH (CLUSTERED INDEX(cohort_definition_id));
\ No newline at end of file
+			cohort_initiation_date date NULL );
\ No newline at end of file
diff --git a/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_indices.sql b/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_indices.sql
index 6bab56cf..277c371d 100644
--- a/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_indices.sql
+++ b/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_indices.sql
@@ -1,84 +1,98 @@
--- azure synapse OMOP CDM Indices
-
-
+/*synapse OMOP CDM Indices
+  There are no unique indices created because it is assumed that the primary key constraints have been run prior to
+  implementing indices.
+*/
 /************************
-
 Standardized clinical data
-
 ************************/
-
+CREATE CLUSTERED INDEX idx_person_id ON @cdmDatabaseSchema.person (person_id ASC);
 CREATE INDEX idx_gender ON @cdmDatabaseSchema.person (gender_concept_id ASC);
-
+CREATE CLUSTERED INDEX idx_observation_period_id_1 ON @cdmDatabaseSchema.observation_period (person_id ASC);
+CREATE CLUSTERED INDEX idx_visit_person_id_1 ON @cdmDatabaseSchema.visit_occurrence (person_id ASC);
 CREATE INDEX idx_visit_concept_id_1 ON @cdmDatabaseSchema.visit_occurrence (visit_concept_id ASC);
-
+CREATE CLUSTERED INDEX idx_visit_det_person_id_1 ON @cdmDatabaseSchema.visit_detail (person_id ASC);
 CREATE INDEX idx_visit_det_concept_id_1 ON @cdmDatabaseSchema.visit_detail (visit_detail_concept_id ASC);
 CREATE INDEX idx_visit_det_occ_id ON @cdmDatabaseSchema.visit_detail (visit_occurrence_id ASC);
-
+CREATE CLUSTERED INDEX idx_condition_person_id_1 ON @cdmDatabaseSchema.condition_occurrence (person_id ASC);
 CREATE INDEX idx_condition_concept_id_1 ON @cdmDatabaseSchema.condition_occurrence (condition_concept_id ASC);
 CREATE INDEX idx_condition_visit_id_1 ON @cdmDatabaseSchema.condition_occurrence (visit_occurrence_id ASC);
-
+CREATE CLUSTERED INDEX idx_drug_person_id_1 ON @cdmDatabaseSchema.drug_exposure (person_id ASC);
 CREATE INDEX idx_drug_concept_id_1 ON @cdmDatabaseSchema.drug_exposure (drug_concept_id ASC);
 CREATE INDEX idx_drug_visit_id_1 ON @cdmDatabaseSchema.drug_exposure (visit_occurrence_id ASC);
-
+CREATE CLUSTERED INDEX idx_procedure_person_id_1 ON @cdmDatabaseSchema.procedure_occurrence (person_id ASC);
 CREATE INDEX idx_procedure_concept_id_1 ON @cdmDatabaseSchema.procedure_occurrence (procedure_concept_id ASC);
 CREATE INDEX idx_procedure_visit_id_1 ON @cdmDatabaseSchema.procedure_occurrence (visit_occurrence_id ASC);
-
+CREATE CLUSTERED INDEX idx_device_person_id_1 ON @cdmDatabaseSchema.device_exposure (person_id ASC);
 CREATE INDEX idx_device_concept_id_1 ON @cdmDatabaseSchema.device_exposure (device_concept_id ASC);
 CREATE INDEX idx_device_visit_id_1 ON @cdmDatabaseSchema.device_exposure (visit_occurrence_id ASC);
-
+CREATE CLUSTERED INDEX idx_measurement_person_id_1 ON @cdmDatabaseSchema.measurement (person_id ASC);
 CREATE INDEX idx_measurement_concept_id_1 ON @cdmDatabaseSchema.measurement (measurement_concept_id ASC);
 CREATE INDEX idx_measurement_visit_id_1 ON @cdmDatabaseSchema.measurement (visit_occurrence_id ASC);
-
+CREATE CLUSTERED INDEX idx_observation_person_id_1 ON @cdmDatabaseSchema.observation (person_id ASC);
 CREATE INDEX idx_observation_concept_id_1 ON @cdmDatabaseSchema.observation (observation_concept_id ASC);
 CREATE INDEX idx_observation_visit_id_1 ON @cdmDatabaseSchema.observation (visit_occurrence_id ASC);
-
+CREATE CLUSTERED INDEX idx_death_person_id_1 ON @cdmDatabaseSchema.death (person_id ASC);
+CREATE CLUSTERED INDEX idx_note_person_id_1 ON @cdmDatabaseSchema.note (person_id ASC);
 CREATE INDEX idx_note_concept_id_1 ON @cdmDatabaseSchema.note (note_type_concept_id ASC);
 CREATE INDEX idx_note_visit_id_1 ON @cdmDatabaseSchema.note (visit_occurrence_id ASC);
-
+CREATE CLUSTERED INDEX idx_note_nlp_note_id_1 ON @cdmDatabaseSchema.note_nlp (note_id ASC);
 CREATE INDEX idx_note_nlp_concept_id_1 ON @cdmDatabaseSchema.note_nlp (note_nlp_concept_id ASC);
-
+CREATE CLUSTERED INDEX idx_specimen_person_id_1 ON @cdmDatabaseSchema.specimen (person_id ASC);
 CREATE INDEX idx_specimen_concept_id_1 ON @cdmDatabaseSchema.specimen (specimen_concept_id ASC);
-
 CREATE INDEX idx_fact_relationship_id1 ON @cdmDatabaseSchema.fact_relationship (domain_concept_id_1 ASC);
 CREATE INDEX idx_fact_relationship_id2 ON @cdmDatabaseSchema.fact_relationship (domain_concept_id_2 ASC);
 CREATE INDEX idx_fact_relationship_id3 ON @cdmDatabaseSchema.fact_relationship (relationship_concept_id ASC);
-
 /************************
-
+Standardized health system data
+************************/
+CREATE CLUSTERED INDEX idx_location_id_1 ON @cdmDatabaseSchema.location (location_id ASC);
+CREATE CLUSTERED INDEX idx_care_site_id_1 ON @cdmDatabaseSchema.care_site (care_site_id ASC);
+CREATE CLUSTERED INDEX idx_provider_id_1 ON @cdmDatabaseSchema.provider (provider_id ASC);
+/************************
 Standardized health economics
-
 ************************/
-
+CREATE CLUSTERED INDEX idx_period_person_id_1 ON @cdmDatabaseSchema.payer_plan_period (person_id ASC);
 CREATE INDEX idx_cost_event_id  ON @cdmDatabaseSchema.cost (cost_event_id ASC);
-
 /************************
-
 Standardized derived elements
-
 ************************/
+CREATE CLUSTERED INDEX idx_drug_era_person_id_1 ON @cdmDatabaseSchema.drug_era (person_id ASC);
 CREATE INDEX idx_drug_era_concept_id_1 ON @cdmDatabaseSchema.drug_era (drug_concept_id ASC);
-
+CREATE CLUSTERED INDEX idx_dose_era_person_id_1 ON @cdmDatabaseSchema.dose_era (person_id ASC);
 CREATE INDEX idx_dose_era_concept_id_1 ON @cdmDatabaseSchema.dose_era (drug_concept_id ASC);
-
+CREATE CLUSTERED INDEX idx_condition_era_person_id_1 ON @cdmDatabaseSchema.condition_era (person_id ASC);
 CREATE INDEX idx_condition_era_concept_id_1 ON @cdmDatabaseSchema.condition_era (condition_concept_id ASC);
-
 /**************************
-
+Standardized meta-data
+***************************/
+CREATE CLUSTERED INDEX idx_metadata_concept_id_1 ON @cdmDatabaseSchema.metadata (metadata_concept_id ASC);
+/**************************
 Standardized vocabularies
-
 ***************************/
+CREATE CLUSTERED INDEX idx_concept_concept_id ON @cdmDatabaseSchema.concept (concept_id ASC);
 CREATE INDEX idx_concept_code ON @cdmDatabaseSchema.concept (concept_code ASC);
 CREATE INDEX idx_concept_vocabluary_id ON @cdmDatabaseSchema.concept (vocabulary_id ASC);
 CREATE INDEX idx_concept_domain_id ON @cdmDatabaseSchema.concept (domain_id ASC);
 CREATE INDEX idx_concept_class_id ON @cdmDatabaseSchema.concept (concept_class_id ASC);
-
+CREATE CLUSTERED INDEX idx_vocabulary_vocabulary_id ON @cdmDatabaseSchema.vocabulary (vocabulary_id ASC);
+CREATE CLUSTERED INDEX idx_domain_domain_id ON @cdmDatabaseSchema.domain (domain_id ASC);
+CREATE CLUSTERED INDEX idx_concept_class_class_id ON @cdmDatabaseSchema.concept_class (concept_class_id ASC);
+CREATE CLUSTERED INDEX idx_concept_relationship_id_1 ON @cdmDatabaseSchema.concept_relationship (concept_id_1 ASC);
 CREATE INDEX idx_concept_relationship_id_2 ON @cdmDatabaseSchema.concept_relationship (concept_id_2 ASC);
 CREATE INDEX idx_concept_relationship_id_3 ON @cdmDatabaseSchema.concept_relationship (relationship_id ASC);
-
+CREATE CLUSTERED INDEX idx_relationship_rel_id ON @cdmDatabaseSchema.relationship (relationship_id ASC);
+CREATE CLUSTERED INDEX idx_concept_synonym_id ON @cdmDatabaseSchema.concept_synonym (concept_id ASC);
+CREATE CLUSTERED INDEX idx_concept_ancestor_id_1 ON @cdmDatabaseSchema.concept_ancestor (ancestor_concept_id ASC);
 CREATE INDEX idx_concept_ancestor_id_2 ON @cdmDatabaseSchema.concept_ancestor (descendant_concept_id ASC);
-
+CREATE CLUSTERED INDEX idx_source_to_concept_map_3 ON @cdmDatabaseSchema.source_to_concept_map (target_concept_id ASC);
 CREATE INDEX idx_source_to_concept_map_1 ON @cdmDatabaseSchema.source_to_concept_map (source_vocabulary_id ASC);
 CREATE INDEX idx_source_to_concept_map_2 ON @cdmDatabaseSchema.source_to_concept_map (target_vocabulary_id ASC);
 CREATE INDEX idx_source_to_concept_map_c ON @cdmDatabaseSchema.source_to_concept_map (source_code ASC);
-
-CREATE INDEX idx_drug_strength_id_2 ON @cdmDatabaseSchema.drug_strength (ingredient_concept_id ASC);
\ No newline at end of file
+CREATE CLUSTERED INDEX idx_drug_strength_id_1 ON @cdmDatabaseSchema.drug_strength (drug_concept_id ASC);
+CREATE INDEX idx_drug_strength_id_2 ON @cdmDatabaseSchema.drug_strength (ingredient_concept_id ASC);
+--Additional v6.0 indices
+--CREATE CLUSTERED INDEX idx_survey_person_id_1 ON @cdmDatabaseSchema.survey_conduct (person_id ASC);
+--CREATE CLUSTERED INDEX idx_episode_person_id_1 ON @cdmDatabaseSchema.episode (person_id ASC);
+--CREATE INDEX idx_episode_concept_id_1 ON @cdmDatabaseSchema.episode (episode_concept_id ASC);
+--CREATE CLUSTERED INDEX idx_episode_event_id_1 ON @cdmDatabaseSchema.episode_event (episode_id ASC);
+--CREATE INDEX idx_ee_field_concept_id_1 ON @cdmDatabaseSchema.episode_event (event_field_concept_id ASC);
diff --git a/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_primary_keys.sql b/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_primary_keys.sql
index 7ae3bf17..1023e1b8 100644
--- a/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_primary_keys.sql
+++ b/inst/ddl/5.4/synapse/OMOPCDM_synapse_5.4_primary_keys.sql
@@ -1,57 +1,29 @@
--- azure synapse CDM Primary Key Constraints for OMOP Common Data Model 5.4
-
-ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT xpk_PERSON PRIMARY KEY NONCLUSTERED (person_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT xpk_OBSERVATION_PERIOD PRIMARY KEY NONCLUSTERED (observation_period_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT xpk_VISIT_OCCURRENCE PRIMARY KEY NONCLUSTERED (visit_occurrence_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT xpk_VISIT_DETAIL PRIMARY KEY NONCLUSTERED (visit_detail_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT xpk_CONDITION_OCCURRENCE PRIMARY KEY NONCLUSTERED (condition_occurrence_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT xpk_DRUG_EXPOSURE PRIMARY KEY NONCLUSTERED (drug_exposure_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT xpk_PROCEDURE_OCCURRENCE PRIMARY KEY NONCLUSTERED (procedure_occurrence_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT xpk_DEVICE_EXPOSURE PRIMARY KEY NONCLUSTERED (device_exposure_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT xpk_MEASUREMENT PRIMARY KEY NONCLUSTERED (measurement_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT xpk_OBSERVATION PRIMARY KEY NONCLUSTERED (observation_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT xpk_NOTE PRIMARY KEY NONCLUSTERED (note_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT xpk_NOTE_NLP PRIMARY KEY NONCLUSTERED (note_nlp_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT xpk_SPECIMEN PRIMARY KEY NONCLUSTERED (specimen_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT xpk_LOCATION PRIMARY KEY NONCLUSTERED (location_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT xpk_CARE_SITE PRIMARY KEY NONCLUSTERED (care_site_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT xpk_PROVIDER PRIMARY KEY NONCLUSTERED (provider_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT xpk_PAYER_PLAN_PERIOD PRIMARY KEY NONCLUSTERED (payer_plan_period_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT xpk_COST PRIMARY KEY NONCLUSTERED (cost_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT xpk_DRUG_ERA PRIMARY KEY NONCLUSTERED (drug_era_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT xpk_DOSE_ERA PRIMARY KEY NONCLUSTERED (dose_era_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT xpk_CONDITION_ERA PRIMARY KEY NONCLUSTERED (condition_era_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT xpk_EPISODE PRIMARY KEY NONCLUSTERED (episode_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT xpk_METADATA PRIMARY KEY NONCLUSTERED (metadata_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT xpk_CONCEPT PRIMARY KEY NONCLUSTERED (concept_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT xpk_VOCABULARY PRIMARY KEY NONCLUSTERED (vocabulary_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT xpk_DOMAIN PRIMARY KEY NONCLUSTERED (domain_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT xpk_CONCEPT_CLASS PRIMARY KEY NONCLUSTERED (concept_class_id) NOT ENFORCED;
-
-ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY NONCLUSTERED (relationship_id) NOT ENFORCED;
+--synapse CDM Primary Key Constraints for OMOP Common Data Model 5.4
+ALTER TABLE @cdmDatabaseSchema.PERSON ADD CONSTRAINT xpk_PERSON PRIMARY KEY NONCLUSTERED (person_id);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION_PERIOD ADD CONSTRAINT xpk_OBSERVATION_PERIOD PRIMARY KEY NONCLUSTERED (observation_period_id);
+ALTER TABLE @cdmDatabaseSchema.VISIT_OCCURRENCE ADD CONSTRAINT xpk_VISIT_OCCURRENCE PRIMARY KEY NONCLUSTERED (visit_occurrence_id);
+ALTER TABLE @cdmDatabaseSchema.VISIT_DETAIL ADD CONSTRAINT xpk_VISIT_DETAIL PRIMARY KEY NONCLUSTERED (visit_detail_id);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_OCCURRENCE ADD CONSTRAINT xpk_CONDITION_OCCURRENCE PRIMARY KEY NONCLUSTERED (condition_occurrence_id);
+ALTER TABLE @cdmDatabaseSchema.DRUG_EXPOSURE ADD CONSTRAINT xpk_DRUG_EXPOSURE PRIMARY KEY NONCLUSTERED (drug_exposure_id);
+ALTER TABLE @cdmDatabaseSchema.PROCEDURE_OCCURRENCE ADD CONSTRAINT xpk_PROCEDURE_OCCURRENCE PRIMARY KEY NONCLUSTERED (procedure_occurrence_id);
+ALTER TABLE @cdmDatabaseSchema.DEVICE_EXPOSURE ADD CONSTRAINT xpk_DEVICE_EXPOSURE PRIMARY KEY NONCLUSTERED (device_exposure_id);
+ALTER TABLE @cdmDatabaseSchema.MEASUREMENT ADD CONSTRAINT xpk_MEASUREMENT PRIMARY KEY NONCLUSTERED (measurement_id);
+ALTER TABLE @cdmDatabaseSchema.OBSERVATION ADD CONSTRAINT xpk_OBSERVATION PRIMARY KEY NONCLUSTERED (observation_id);
+ALTER TABLE @cdmDatabaseSchema.NOTE ADD CONSTRAINT xpk_NOTE PRIMARY KEY NONCLUSTERED (note_id);
+ALTER TABLE @cdmDatabaseSchema.NOTE_NLP ADD CONSTRAINT xpk_NOTE_NLP PRIMARY KEY NONCLUSTERED (note_nlp_id);
+ALTER TABLE @cdmDatabaseSchema.SPECIMEN ADD CONSTRAINT xpk_SPECIMEN PRIMARY KEY NONCLUSTERED (specimen_id);
+ALTER TABLE @cdmDatabaseSchema.LOCATION ADD CONSTRAINT xpk_LOCATION PRIMARY KEY NONCLUSTERED (location_id);
+ALTER TABLE @cdmDatabaseSchema.CARE_SITE ADD CONSTRAINT xpk_CARE_SITE PRIMARY KEY NONCLUSTERED (care_site_id);
+ALTER TABLE @cdmDatabaseSchema.PROVIDER ADD CONSTRAINT xpk_PROVIDER PRIMARY KEY NONCLUSTERED (provider_id);
+ALTER TABLE @cdmDatabaseSchema.PAYER_PLAN_PERIOD ADD CONSTRAINT xpk_PAYER_PLAN_PERIOD PRIMARY KEY NONCLUSTERED (payer_plan_period_id);
+ALTER TABLE @cdmDatabaseSchema.COST ADD CONSTRAINT xpk_COST PRIMARY KEY NONCLUSTERED (cost_id);
+ALTER TABLE @cdmDatabaseSchema.DRUG_ERA ADD CONSTRAINT xpk_DRUG_ERA PRIMARY KEY NONCLUSTERED (drug_era_id);
+ALTER TABLE @cdmDatabaseSchema.DOSE_ERA ADD CONSTRAINT xpk_DOSE_ERA PRIMARY KEY NONCLUSTERED (dose_era_id);
+ALTER TABLE @cdmDatabaseSchema.CONDITION_ERA ADD CONSTRAINT xpk_CONDITION_ERA PRIMARY KEY NONCLUSTERED (condition_era_id);
+ALTER TABLE @cdmDatabaseSchema.EPISODE ADD CONSTRAINT xpk_EPISODE PRIMARY KEY NONCLUSTERED (episode_id);
+ALTER TABLE @cdmDatabaseSchema.METADATA ADD CONSTRAINT xpk_METADATA PRIMARY KEY NONCLUSTERED (metadata_id);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT ADD CONSTRAINT xpk_CONCEPT PRIMARY KEY NONCLUSTERED (concept_id);
+ALTER TABLE @cdmDatabaseSchema.VOCABULARY ADD CONSTRAINT xpk_VOCABULARY PRIMARY KEY NONCLUSTERED (vocabulary_id);
+ALTER TABLE @cdmDatabaseSchema.DOMAIN ADD CONSTRAINT xpk_DOMAIN PRIMARY KEY NONCLUSTERED (domain_id);
+ALTER TABLE @cdmDatabaseSchema.CONCEPT_CLASS ADD CONSTRAINT xpk_CONCEPT_CLASS PRIMARY KEY NONCLUSTERED (concept_class_id);
+ALTER TABLE @cdmDatabaseSchema.RELATIONSHIP ADD CONSTRAINT xpk_RELATIONSHIP PRIMARY KEY NONCLUSTERED (relationship_id);
diff --git a/man/createDdl.Rd b/man/createDdl.Rd
index 8030fa3f..dfd8612d 100644
--- a/man/createDdl.Rd
+++ b/man/createDdl.Rd
@@ -30,11 +30,11 @@ Dashboard.
 }
 \section{Functions}{
 \itemize{
-\item \code{createPrimaryKeys}: createPrimaryKeys Returns a string containing the OHDSQL for creation of primary keys in the OMOP CDM.
+\item \code{createPrimaryKeys()}: createPrimaryKeys Returns a string containing the OHDSQL for creation of primary keys in the OMOP CDM.
 
-\item \code{createForeignKeys}: createForeignKeys Returns a string containing the OHDSQL for creation of foreign keys in the OMOP CDM.
-}}
+\item \code{createForeignKeys()}: createForeignKeys Returns a string containing the OHDSQL for creation of foreign keys in the OMOP CDM.
 
+}}
 \examples{
 ddl <- createDdl("5.4")
 pk <- createPrimaryKeys("5.4")
diff --git a/man/writeDdl.Rd b/man/writeDdl.Rd
index 0014b395..26e9de0b 100644
--- a/man/writeDdl.Rd
+++ b/man/writeDdl.Rd
@@ -36,7 +36,8 @@ writeIndex(
 )
 }
 \arguments{
-\item{targetDialect}{The dialect of the target database. Choices are "oracle", "postgresql", "pdw", "redshift", "impala", "netezza", "bigquery", "sql server"}
+\item{targetDialect}{The dialect of the target database. Choices are "oracle", "postgresql", "pdw", "redshift", "impala", "netezza", "bigquery", "sql server",
+"spark", "snowflake", "synapse"}
 
 \item{cdmVersion}{The version of the CDM you are creating, e.g. 5.3, 5.4}
 
@@ -52,10 +53,10 @@ execution.
 }
 \section{Functions}{
 \itemize{
-\item \code{writePrimaryKeys}: writePrimaryKeys Write the SQL code that creates the primary keys to a file.
+\item \code{writePrimaryKeys()}: writePrimaryKeys Write the SQL code that creates the primary keys to a file.
 
-\item \code{writeForeignKeys}: writeForeignKeys Write the SQL code that creates the foreign keys to a file.
+\item \code{writeForeignKeys()}: writeForeignKeys Write the SQL code that creates the foreign keys to a file.
 
-\item \code{writeIndex}: writeIndex Write the rendered and translated sql that creates recommended indexes to a file.
-}}
+\item \code{writeIndex()}: writeIndex Write the rendered and translated sql that creates recommended indexes to a file.
 
+}}
diff --git a/rmd/cdm53.Rmd b/rmd/cdm53.Rmd
index 737d50df..b8076ce5 100644
--- a/rmd/cdm53.Rmd
+++ b/rmd/cdm53.Rmd
@@ -90,7 +90,7 @@ for(tb in tables) {
   loopTable <- subset(cdmSpecsClean, `CDM Table` == tb)
   loopTable <- subset(loopTable, select = -c(1))
  
-  print(kable(x = loopTable, align = "l", row.names = FALSE, format = "html", escape = FALSE) %>%
+  print(knitr::kable(x = loopTable, align = "l", row.names = FALSE, format = "html", escape = FALSE) %>%
            column_spec(1, bold = T) %>%
            # column_spec(2, width = "3in", include_thead = T) %>%
            # column_spec(3, width = "4in", include_thead = T) %>%
diff --git a/rmd/cdm54.Rmd b/rmd/cdm54.Rmd
index b61f3cf9..87e5b388 100644
--- a/rmd/cdm54.Rmd
+++ b/rmd/cdm54.Rmd
@@ -106,7 +106,7 @@ for(tb in tables) {
   loopTable <- subset(cdmSpecsClean, `CDM Table` == tb)
   loopTable <- subset(loopTable, select = -c(1))
  
-  print(kable(x = loopTable, align = "l", row.names = FALSE, format = "html", escape = FALSE) %>%
+  print(knitr::kable(x = loopTable, align = "l", row.names = FALSE, format = "html", escape = FALSE) %>%
            column_spec(1, bold = T) %>%
            # column_spec(2, width = "3in", include_thead = T) %>%
            # column_spec(3, width = "4in", include_thead = T) %>%
diff --git a/rmd/cdm60.Rmd b/rmd/cdm60.Rmd
index 5bffe5c6..f01601a0 100644
--- a/rmd/cdm60.Rmd
+++ b/rmd/cdm60.Rmd
@@ -102,7 +102,7 @@ for(tb in tables) {
   loopTable <- subset(cdmSpecsClean, `CDM Table` == tb)
   loopTable <- subset(loopTable, select = -c(1))
  
-  print(kable(x = loopTable, align = "l", row.names = FALSE, format = "html") %>% 
+  print(knitr::kable(x = loopTable, align = "l", row.names = FALSE, format = "html") %>% 
            column_spec(1, bold = T) %>%
            # column_spec(2, width = "3in", include_thead = T) %>%
            # column_spec(3, width = "4in", include_thead = T) %>%