1566 lines
67 KiB
HTML
1566 lines
67 KiB
HTML
<!DOCTYPE html>
|
||
|
||
<html>
|
||
|
||
<head>
|
||
|
||
<meta charset="utf-8" />
|
||
<meta name="generator" content="pandoc" />
|
||
<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />
|
||
|
||
|
||
|
||
|
||
<title>OMOP CDM v6.0</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="cdm60.html">CDM v6.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">NEW 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>
|
||
</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">
|
||
|
||
|
||
|
||
<h1 class="title toc-ignore"><strong>OMOP CDM v6.0</strong></h1>
|
||
|
||
</div>
|
||
|
||
|
||
<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>
|
||
</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>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>
|
||
</ul>
|
||
<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><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>
|
||
</div>
|
||
<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><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><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>
|
||
</div>
|
||
<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><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>
|
||
<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>
|
||
</ul>
|
||
<p>The Visit duration, or ‘length of stay’, is defined as VISIT_END_DATE
|
||
- VISIT_START_DATE. For all Visits this is <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>
|
||
</div>
|
||
<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><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><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>
|
||
</div>
|
||
<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><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><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>
|
||
</div>
|
||
<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><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><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>
|
||
</div>
|
||
<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><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><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>
|
||
</div>
|
||
<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><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><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>
|
||
</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 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 (<, >, 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>
|
||
</div>
|
||
<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><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><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>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</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>
|
||
<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>
|
||
</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>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</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>
|
||
</div>
|
||
<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&standardConcept=Standard&page=2&pageSize=15&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>User Guide</strong></p>
|
||
<p>NA</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>
|
||
</div>
|
||
<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><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><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>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</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>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</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>
|
||
</div>
|
||
<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><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><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><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><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><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><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>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</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>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</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>
|
||
</div>
|
||
<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>
|
||
<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>
|
||
</ul>
|
||
<p><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<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>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</div>
|
||
<div id="cohort" class="section level3 tabset tabset-pills">
|
||
<h3 class="tabset tabset-pills">cohort</h3>
|
||
<p><strong>Table Description</strong></p>
|
||
<p>The COHORT table contains records of subjects that satisfy a given
|
||
set of criteria for a duration of time. The definition of the cohort is
|
||
contained within the COHORT_DEFINITION table. It is listed as part of
|
||
the RESULTS schema because it is a table that users of the database as
|
||
well as tools such as ATLAS need to be able to write to. The CDM and
|
||
Vocabulary tables are all read-only so it is suggested that the COHORT
|
||
and COHORT_DEFINTION tables are kept in a separate schema to alleviate
|
||
confusion.</p>
|
||
<p><strong>User Guide</strong></p>
|
||
<p>NA</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>
|
||
</div>
|
||
<div id="cohort_definition" class="section level3 tabset tabset-pills">
|
||
<h3 class="tabset tabset-pills">cohort_definition</h3>
|
||
<p><strong>Table Description</strong></p>
|
||
<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><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>NA</p>
|
||
</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,h4,h5",
|
||
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>
|