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

1308 lines
50 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />
<title>dataModelConventions.knit</title>
<script src="site_libs/header-attrs-2.25/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" />
<script src="site_libs/bootstrap-3.3.5/js/bootstrap.min.js"></script>
<script src="site_libs/bootstrap-3.3.5/shim/html5shiv.min.js"></script>
<script src="site_libs/bootstrap-3.3.5/shim/respond.min.js"></script>
<style>h1 {font-size: 34px;}
h1.title {font-size: 38px;}
h2 {font-size: 30px;}
h3 {font-size: 24px;}
h4 {font-size: 18px;}
h5 {font-size: 16px;}
h6 {font-size: 12px;}
code {color: inherit; background-color: rgba(0, 0, 0, 0.04);}
pre:not([class]) { background-color: white }</style>
<script src="site_libs/jqueryui-1.13.2/jquery-ui.min.js"></script>
<link href="site_libs/tocify-1.9.1/jquery.tocify.css" rel="stylesheet" />
<script src="site_libs/tocify-1.9.1/jquery.tocify.js"></script>
<script src="site_libs/navigation-1.1/tabsets.js"></script>
<link href="site_libs/highlightjs-9.12.0/default.css" rel="stylesheet" />
<script src="site_libs/highlightjs-9.12.0/highlight.js"></script>
<link href="site_libs/font-awesome-6.4.2/css/all.min.css" rel="stylesheet" />
<link href="site_libs/font-awesome-6.4.2/css/v4-shims.min.css" rel="stylesheet" />
<link rel='shortcut icon' type='image/x-icon' href='favicon.ico' />
<style type="text/css">
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
</style>
<style type="text/css">code{white-space: pre;}</style>
<script type="text/javascript">
if (window.hljs) {
hljs.configure({languages: []});
hljs.initHighlightingOnLoad();
if (document.readyState && document.readyState === "complete") {
window.setTimeout(function() { hljs.initHighlighting(); }, 0);
}
}
</script>
<link rel="stylesheet" href="style.css" type="text/css" />
<style type = "text/css">
.main-container {
max-width: 940px;
margin-left: auto;
margin-right: auto;
}
img {
max-width:100%;
}
.tabbed-pane {
padding-top: 12px;
}
.html-widget {
margin-bottom: 20px;
}
button.code-folding-btn:focus {
outline: none;
}
summary {
display: list-item;
}
details > summary > p:only-child {
display: inline;
}
pre code {
padding: 0;
}
</style>
<style type="text/css">
.dropdown-submenu {
position: relative;
}
.dropdown-submenu>.dropdown-menu {
top: 0;
left: 100%;
margin-top: -6px;
margin-left: -1px;
border-radius: 0 6px 6px 6px;
}
.dropdown-submenu:hover>.dropdown-menu {
display: block;
}
.dropdown-submenu>a:after {
display: block;
content: " ";
float: right;
width: 0;
height: 0;
border-color: transparent;
border-style: solid;
border-width: 5px 0 5px 5px;
border-left-color: #cccccc;
margin-top: 5px;
margin-right: -10px;
}
.dropdown-submenu:hover>a:after {
border-left-color: #adb5bd;
}
.dropdown-submenu.pull-left {
float: none;
}
.dropdown-submenu.pull-left>.dropdown-menu {
left: -100%;
margin-left: 10px;
border-radius: 6px 0 6px 6px;
}
</style>
<script type="text/javascript">
// manage active state of menu based on current page
$(document).ready(function () {
// active menu anchor
href = window.location.pathname
href = href.substr(href.lastIndexOf('/') + 1)
if (href === "")
href = "index.html";
var menuAnchor = $('a[href="' + href + '"]');
// 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;
var style = document.createElement('style');
var pt = "padding-top: " + navHeight + "px; ";
var mt = "margin-top: -" + navHeight + "px; ";
var css = "";
// offset scroll position for anchor links (for fixed navbar)
for (var i = 1; i <= 6; i++) {
css += ".section h" + i + "{ " + pt + mt + "}\n";
}
style.innerHTML = "body {" + pt + "padding-bottom: 40px; }\n" + css;
document.head.appendChild(style);
});
</script>
<!-- tabsets -->
<style type="text/css">
.tabset-dropdown > .nav-tabs {
display: inline-table;
max-height: 500px;
min-height: 44px;
overflow-y: auto;
border: 1px solid #ddd;
border-radius: 4px;
}
.tabset-dropdown > .nav-tabs > li.active:before, .tabset-dropdown > .nav-tabs.nav-tabs-open:before {
content: "\e259";
font-family: 'Glyphicons Halflings';
display: inline-block;
padding: 10px;
border-right: 1px solid #ddd;
}
.tabset-dropdown > .nav-tabs.nav-tabs-open > li.active:before {
content: "\e258";
font-family: 'Glyphicons Halflings';
border: none;
}
.tabset-dropdown > .nav-tabs > li.active {
display: block;
}
.tabset-dropdown > .nav-tabs > li > a,
.tabset-dropdown > .nav-tabs > li > a:focus,
.tabset-dropdown > .nav-tabs > li > a:hover {
border: none;
display: inline-block;
border-radius: 4px;
background-color: transparent;
}
.tabset-dropdown > .nav-tabs.nav-tabs-open > li {
display: block;
float: none;
}
.tabset-dropdown > .nav-tabs > li {
display: none;
}
</style>
<!-- code folding -->
<style type="text/css">
#TOC {
margin: 25px 0px 20px 0px;
}
@media (max-width: 768px) {
#TOC {
position: relative;
width: 100%;
}
}
@media print {
.toc-content {
/* see https://github.com/w3c/csswg-drafts/issues/4434 */
float: right;
}
}
.toc-content {
padding-left: 30px;
padding-right: 40px;
}
div.main-container {
max-width: 1200px;
}
div.tocify {
width: 20%;
max-width: 260px;
max-height: 85%;
}
@media (min-width: 768px) and (max-width: 991px) {
div.tocify {
width: 25%;
}
}
@media (max-width: 767px) {
div.tocify {
width: 100%;
max-width: none;
}
}
.tocify ul, .tocify li {
line-height: 20px;
}
.tocify-subheader .tocify-item {
font-size: 0.90em;
}
.tocify .list-group-item {
border-radius: 0px;
}
</style>
</head>
<body>
<div class="container-fluid main-container">
<!-- setup 3col/9col grid for toc_float and main content -->
<div class="row">
<div class="col-xs-12 col-sm-4 col-md-3">
<div id="TOC" class="tocify">
</div>
</div>
<div class="toc-content col-xs-12 col-sm-8 col-md-9">
<div class="navbar navbar-default navbar-fixed-top" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-bs-toggle="collapse" data-target="#navbar" data-bs-target="#navbar">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="index.html"><div><img src="ohdsi16x16.png"></img> OMOP Common Data Model </div></a>
</div>
<div id="navbar" class="navbar-collapse collapse">
<ul class="nav navbar-nav">
<li>
<a href="index.html">
<span class="fa fa-house"></span>
</a>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-landmark"></span>
Background
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="background.html">Model Background</a>
</li>
<li>
<a href="cdmRefreshProcess.html">CDM Refresh Process</a>
</li>
<li>
<a href="vocabulary.html">How the Vocabulary is Built</a>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-list-alt"></span>
Conventions
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="dataModelConventions.html">General Conventions</a>
</li>
<li>
<a href="ehrObsPeriods.html">Observation Periods for EHR Data</a>
</li>
<li>
<a href="cdmPrivacy.html">Patient Privacy and OMOP</a>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-history"></span>
CDM Versions
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="cdm30.html">CDM v3.0</a>
</li>
<li>
<a href="cdm53.html">CDM v5.3</a>
</li>
<li class="dropdown-submenu">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">CDM v5.4</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="cdm54.html">CDM v5.4</a>
</li>
<li>
<a href="cdm54Changes.html">Changes from CDM v5.3</a>
</li>
<li>
<a href="cdm54erd.html">Entity Relationships</a>
</li>
<li>
<a href="cdm54ToolingSupport.html">Detailed tooling support per CDM field</a>
</li>
</ul>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-plus-square"></span>
CDM Proposals
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="cdmRequestProcess.html">How to Propose Changes to the CDM</a>
</li>
<li>
<a href="https://github.com/OHDSI/CommonDataModel/issues?q=is%3Aopen+is%3Aissue+label%3AProposal">Under Review</a>
</li>
<li class="dropdown-submenu">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">Accepted</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="https://github.com/OHDSI/CommonDataModel/issues/252">Region_concept_id</a>
</li>
</ul>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-question"></span>
How to
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="download.html">Download the DDL</a>
</li>
<li>
<a href="cdmRPackage.html">Use the CDM R Package</a>
</li>
<li>
<a href="drug_dose.html">Calculate Drug Dose</a>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-life-ring"></span>
Support
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="cdmDecisionTree.html">Help! My Data Doesn't Fit!</a>
</li>
<li>
<a href="faq.html">FAQ</a>
</li>
<li>
<a href="sqlScripts.html">SQL Scripts</a>
</li>
<li>
<a href="contribute.html">Ask a Question</a>
</li>
</ul>
</li>
</ul>
<ul class="nav navbar-nav navbar-right">
<li>
<a href="https://github.com/OHDSI/CommonDataModel">
<span class="fa fa-github"></span>
</a>
</li>
</ul>
</div><!--/.nav-collapse -->
</div><!--/.container -->
</div><!--/.navbar -->
<div id="header">
</div>
<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>
<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>
<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>
</div>
<div id="fields" class="section level3">
<h3>Fields</h3>
<p>Variable names across all tables follow one convention:</p>
<table>
<colgroup>
<col width="29%" />
<col width="70%" />
</colgroup>
<thead>
<tr class="header">
<th>Notation</th>
<th>Description</th>
</tr>
</thead>
<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>
</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>
</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>
</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>
</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>
</tr>
</tbody>
</table>
</div>
</div>
<div id="vocabulary" class="section level2">
<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>
<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>
</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>
</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>
</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>
</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:
<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>
</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 hierarchical 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>
</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>Currently, only English Synonyms are included.</li>
</ul>
</div>
<div id="concept-ancestor" class="section level3">
<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>
</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>
</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>
</ul>
</div>
</div>
<div id="mapping" class="section level2">
<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>
</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>
<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>
</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>
</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>
<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>
</ul>
<table>
<colgroup>
<col width="64%" />
<col width="35%" />
</colgroup>
<thead>
<tr class="header">
<th>Drug Type</th>
<th>Type Concept</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>Inpatient administration</td>
<td>EHR administration record</td>
</tr>
<tr class="even">
<td>Physician administered drug (identified from EHR problem list)</td>
<td>EHR administration record</td>
</tr>
<tr class="odd">
<td>Physician administered drug (identified from referral record)</td>
<td>EHR administration record</td>
</tr>
<tr class="even">
<td>Physician administered drug (identified from EHR observation)</td>
<td>EHR administration record</td>
</tr>
<tr class="odd">
<td>Physician administered drug (identified from EHR order)</td>
<td>EHR administration record</td>
</tr>
<tr class="even">
<td>Prescription dispensed in pharmacy</td>
<td>EHR dispensing record</td>
</tr>
<tr class="odd">
<td>Dispensed in Outpatient office</td>
<td>EHR dispensing record</td>
</tr>
<tr class="even">
<td>Medication list entry</td>
<td>EHR medication list</td>
</tr>
<tr class="odd">
<td>Prescription written</td>
<td>EHR prescription</td>
</tr>
<tr class="even">
<td></td>
<td>EHR prescription issue record</td>
</tr>
<tr class="odd">
<td>Prescription dispensed through mail order</td>
<td>Mail order record</td>
</tr>
<tr class="even">
<td>NLP derived</td>
<td>NLP</td>
</tr>
<tr class="odd">
<td>Patient Self-Reported Medication</td>
<td>Patient self-report</td>
</tr>
<tr class="even">
<td>Physician administered drug (identified as procedure)</td>
<td>Pharmacy claim</td>
</tr>
<tr class="odd">
<td>Drug era - 0 days persistence window</td>
<td></td>
</tr>
<tr class="even">
<td>Drug era - 30 days persistence window</td>
<td></td>
</tr>
<tr class="odd">
<td>Randomized Drug</td>
<td></td>
</tr>
</tbody>
</table>
</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>
</div>
<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>
<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>
</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>
<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.
<ul>
<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>
<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.
<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>
</ul></li>
<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>
</ul></li>
<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>
</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>
</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>
</div>
</div>
</div>
</div>
</div>
</div>
<script>
// add bootstrap table styles to pandoc tables
function bootstrapStylePandocTables() {
$('tr.odd').parent('tbody').parent('table').addClass('table table-condensed');
}
$(document).ready(function () {
bootstrapStylePandocTables();
});
</script>
<!-- tabsets -->
<script>
$(document).ready(function () {
window.buildTabsets("TOC");
});
$(document).ready(function () {
$('.tabset-dropdown > .nav-tabs > li').click(function () {
$(this).parent().toggleClass('nav-tabs-open');
});
});
</script>
<!-- code folding -->
<script>
$(document).ready(function () {
// temporarily add toc-ignore selector to headers for the consistency with Pandoc
$('.unlisted.unnumbered').addClass('toc-ignore')
// move toc-ignore selectors from section div to header
$('div.section.toc-ignore')
.removeClass('toc-ignore')
.children('h1,h2,h3,h4,h5').addClass('toc-ignore');
// establish options
var options = {
selectors: "h1,h2,h3",
theme: "bootstrap3",
context: '.toc-content',
hashGenerator: function (text) {
return text.replace(/[.\\/?&!#<>]/g, '').replace(/\s/g, '_');
},
ignoreSelector: ".toc-ignore",
scrollTo: 0
};
options.showAndHide = true;
options.smoothScroll = true;
// tocify
var toc = $("#TOC").tocify(options).data("toc-tocify");
});
</script>
<!-- dynamically load mathjax for compatibility with self-contained -->
<script>
(function () {
var script = document.createElement("script");
script.type = "text/javascript";
script.src = "https://mathjax.rstudio.com/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML";
document.getElementsByTagName("head")[0].appendChild(script);
})();
</script>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink