11764 lines
272 KiB
HTML
11764 lines
272 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 v5.3</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>
|
||
<li>
|
||
<a href="customConcepts.html">Custom Concepts</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">
|
||
|
||
|
||
|
||
<h1 class="title toc-ignore"><strong>OMOP CDM v5.3</strong></h1>
|
||
|
||
</div>
|
||
|
||
|
||
<p>Below is the specification document for the OMOP Common Data Model,
|
||
v5.3 (previously v5.3.1). Each table is represented with a high-level
|
||
description and ETL conventions that should be followed. This is
|
||
continued with a discussion of each field in each table, any conventions
|
||
related to the field, and constraints that should be followed (like
|
||
primary key, foreign key, etc). All tables should be instantiated in a
|
||
CDM instance but do not need to be populated. Similarly, fields that are
|
||
not required should exist in the CDM table but do not need to be
|
||
populated. Should you have questions please feel free to visit the <a
|
||
href="https://forums.ohdsi.org/">forums</a> or the <a
|
||
href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a>
|
||
page.</p>
|
||
<p><em><strong>Special Note</strong> This documentation previously
|
||
referenced v5.3.1. During the OHDSI/CommonDataModel Hack-A-Thon that
|
||
occurred on August 18, 2021 the decision was made to align documentation
|
||
with the minor releases. Hot fixes and minor.minor release can be found
|
||
through the searching of tags.</em></p>
|
||
<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
|
||
content of the BIRTH_DATETIME must be equivalent to the content of
|
||
BIRTH_DAY, BIRTH_MONTH and BIRTH_YEAR.<br><br>For detailed conventions
|
||
for how to populate this table, please refer to the <a
|
||
href="https://ohdsi.github.io/Themis/person.html">THEMIS
|
||
repository</a>.</p>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
It is assumed that every person with a different unique identifier is in
|
||
fact a different person and should be treated independently.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Any person linkage that needs to occur to uniquely identify Persons
|
||
ought to be done prior to writing this table. This identifier can be the
|
||
original id from the source data provided if it is an integer, otherwise
|
||
it can be an autogenerated number.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
gender_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field is meant to capture the biological sex at birth of the
|
||
Person. This field should not be used to study gender identity issues.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use the gender or sex value present in the data under the assumption
|
||
that it is the biological sex at birth. If the source data captures
|
||
gender identity it should be stored in the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a>
|
||
table. <a
|
||
href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
gender concepts</a>. Please refer to the <a
|
||
href="https://ohdsi.github.io/Themis/tag_gender_concept_id.html">THEMIS
|
||
repository</a> for detailed conventions on how to populate this field.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Gender
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
year_of_birth
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Compute age using year_of_birth.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
For data sources with date of birth, the year should be extracted. If no
|
||
year of birth is available all the person’s data should be dropped from
|
||
the CDM instance. For additional information on how to populate this
|
||
field, please refer to the <a
|
||
href="https://ohdsi.github.io/Themis/tag_year_of_birth.html">THEMIS
|
||
repository</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
month_of_birth
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
For data sources that provide the precise date of birth, the month
|
||
should be extracted and stored in this field.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
day_of_birth
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
For data sources that provide the precise date of birth, the day should
|
||
be extracted and stored in this field.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
birth_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field is not required but highly encouraged. For data sources that
|
||
provide the precise datetime of birth, that value should be stored in
|
||
this field. For more information on how to populate this field, please
|
||
refer to the <a href="https://ohdsi.github.io/Themis/person.html">THEMIS
|
||
repository</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
race_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field captures race or ethnic background of the person.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Only use this field if you have information about race or ethnic
|
||
background. The Vocabulary contains Concepts about the main races and
|
||
ethnic backgrounds in a hierarchical system. Due to the imprecise nature
|
||
of human races and ethnic backgrounds, this is not a perfect system.
|
||
Mixed races are not supported. If a clear race or ethnic background
|
||
cannot be established, use Concept_Id 0. <a
|
||
href="http://athena.ohdsi.org/search-terms/terms?domain=Race&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Race Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Race
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
ethnicity_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field captures Ethnicity as defined by the Office of Management and
|
||
Budget (OMB) of the US Government: it distinguishes only between
|
||
“Hispanic” and “Not Hispanic”. Races and ethnic backgrounds are not
|
||
stored here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Only use this field if you have US-based data and a source of this
|
||
information. Do not attempt to infer Ethnicity from the race or ethnic
|
||
background of the Person. <a
|
||
href="http://athena.ohdsi.org/search-terms/terms?domain=Ethnicity&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
ethnicity concepts</a>
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Ethnicity
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
location_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The location refers to the physical address of the person. This field
|
||
should capture the last known location of the person.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the location_id from the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a>
|
||
table here that represents the most granular location information for
|
||
the person. For additional information on how to populate this field,
|
||
please refer to the <a
|
||
href="https://ohdsi.github.io/Themis/populate_person_location_id.html">THEMIS
|
||
repository</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
LOCATION
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Provider refers to the last known primary care provider (General
|
||
Practitioner).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the provider_id from the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#provider">PROVIDER</a>
|
||
table of the last known general practitioner of the person. If there are
|
||
multiple providers, it is up to the ETL to decide which to put here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
care_site_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Care Site refers to where the Provider typically provides the
|
||
primary care.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CARE_SITE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to link back to persons in the source data. This is
|
||
typically used for error checking of ETL logic.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Some use cases require the ability to link back to persons in the source
|
||
data. This field allows for the storing of the person value as it
|
||
appears in the source. This field is not required but strongly
|
||
recommended.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
gender_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field is used to store the biological sex of the person from the
|
||
source data. It is not intended for use in standard analytics but for
|
||
reference only.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the assigned sex at birth of the person as it appears in the source
|
||
data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
gender_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Due to the small number of options, this tends to be zero.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data codes asigned sex at birth in a non-standard
|
||
vocabulary, store the concept_id here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
race_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field is used to store the race of the person from the source data.
|
||
It is not intended for use in standard analytics but for reference only.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the race of the person as it appears in the source data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
race_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Due to the small number of options, this tends to be zero.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data codes race in an OMOP supported vocabulary store the
|
||
concept_id here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
ethnicity_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field is used to store the ethnicity of the person from the source
|
||
data. It is not intended for use in standard analytics but for reference
|
||
only.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the person has an ethnicity other than the OMB standard of “Hispanic”
|
||
or “Not Hispanic” store that value from the source data here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
ethnicity_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Due to the small number of options, this tends to be zero.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data codes ethnicity in an OMOP supported vocabulary,
|
||
store the concept_id here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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) absence 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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_period_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
A Person can have multiple discrete Observation Periods which are
|
||
identified by the Observation_Period_Id.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Assign a unique observation_period_id to each discrete Observation
|
||
Period for a Person.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Person ID of the PERSON record for which the Observation Period is
|
||
recorded.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_period_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this date to determine the start date of the Observation Period.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
It is often the case that the idea of Observation Periods does not exist
|
||
in source data. In those cases, the observation_period_start_date can be
|
||
inferred as the earliest Event date available for the Person. In
|
||
insurance claim data, the Observation Period can be considered as the
|
||
time period the Person is enrolled with a payer. If a Person switches
|
||
plans but stays with the same payer, and therefore capturing of data
|
||
continues, that change would be captured in <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">PAYER_PLAN_PERIOD</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_period_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this date to determine the end date of the period for which we can
|
||
assume that all events for a Person are recorded.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
It is often the case that the idea of Observation Periods does not exist
|
||
in source data. In those cases, the observation_period_end_date can be
|
||
inferred as the last Event date available for the Person. In insurance
|
||
claim data, the Observation Period can be considered as the time period
|
||
the Person is enrolled with a payer.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
period_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field can be used to determine the provenance of the Observation
|
||
Period as in whether the period was determined from an insurance
|
||
enrollment file, EHR healthcare encounters, or other sources.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Choose the observation_period_type_concept_id that best represents how
|
||
the period was determined. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this to identify unique interactions between a person and the health
|
||
care system. This identifier links across the other CDM event tables to
|
||
associate events with a visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This should be populated by creating a unique identifier for each unique
|
||
interaction between a person and the healthcare system where the person
|
||
receives a medical good or service over a span of time.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field contains a concept id representing the kind of visit, like
|
||
inpatient or outpatient. All concepts in this field should be standard
|
||
and belong to the Visit domain.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Populate this field based on the kind of visit that took place for the
|
||
person. For example this could be “Inpatient Visit”, “Outpatient Visit”,
|
||
“Ambulatory Visit”, etc. This table will contain standard concepts in
|
||
the Visit domain. These concepts are arranged in a hierarchical
|
||
structure to facilitate cohort definitions by rolling up to generally
|
||
familiar Visits adopted in most healthcare systems worldwide. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Visit
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
For inpatient visits, the start date is typically the admission date.
|
||
For outpatient visits the start date and end date will be the same.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
When populating VISIT_START_DATE, you should think about the patient
|
||
experience to make decisions on how to define visits. In the case of an
|
||
inpatient visit this should be the date the patient was admitted to the
|
||
hospital or institution. In all other cases this should be the date of
|
||
the patient-provider interaction.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_start_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If no time is given for the start date of a visit, set it to midnight
|
||
(00:00:0000).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
For inpatient visits the end date is typically the discharge date.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Visit end dates are mandatory. If end dates are not provided in the
|
||
source there are three ways in which to derive them: - Outpatient Visit:
|
||
visit_end_datetime = visit_start_datetime - Emergency Room Visit:
|
||
visit_end_datetime = visit_start_datetime - Inpatient Visit: Usually
|
||
there is information about discharge. If not, you should be able to
|
||
derive the end date from the sudden decline of activity or from the
|
||
absence of inpatient procedures/drugs. - Non-hospital institution
|
||
Visits: Particularly for claims data, if end dates are not provided
|
||
assume the visit is for the duration of month that it occurs. For
|
||
Inpatient Visits ongoing at the date of ETL, put date of processing the
|
||
data into visit_end_datetime and visit_type_concept_id with 32220 “Still
|
||
patient” to identify the visit as incomplete. - All other Visits:
|
||
visit_end_datetime = visit_start_datetime. If this is a one-day visit
|
||
the end date should match the start date.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_end_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If no time is given for the end date of a visit, set it to midnight
|
||
(00:00:0000).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to understand the provenance of the visit record, or
|
||
where the record comes from.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Populate this field based on the provenance of the visit record, as in
|
||
whether it came from an EHR record or billing claim. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
There will only be one provider per visit record and the ETL document
|
||
should clearly state how they were chosen (attending, admitting, etc.).
|
||
If there are multiple providers associated with a visit in the source,
|
||
this can be reflected in the event tables (CONDITION_OCCURRENCE,
|
||
PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If there are multiple providers associated with a visit, you will need
|
||
to choose which one to put here. The additional providers can be stored
|
||
in the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#visit_detail">VISIT_DETAIL</a>
|
||
table.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
care_site_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field provides information about the Care Site where the Visit took
|
||
place.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
There should only be one Care Site associated with a Visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CARE_SITE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the kind of visit that took place (inpatient, outpatient, emergency,
|
||
etc.)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If there is information about the kind of visit in the source data that
|
||
value should be stored here. If a visit is an amalgamation of visits
|
||
from the source then use a hierarchy to choose the visit source value,
|
||
such as IP -> ER-> OP. This should line up with the logic chosen
|
||
to determine how visits are created.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the visit source value is coded in the source data using an OMOP
|
||
supported vocabulary put the concept id representing the source value
|
||
here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
admitting_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to determine where the patient was admitted from. This
|
||
concept is part of the visit domain and can indicate if a patient was
|
||
admitted to the hospital from a long-term care facility, for example.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If available, map the admitted_from_source_value to a standard concept
|
||
in the visit domain. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Visit
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
admitting_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This information may be called something different in the source data
|
||
but the field is meant to contain a value indicating where a person was
|
||
admitted from. Typically this applies only to visits that have a length
|
||
of stay, like inpatient visits or long-term care visits.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
discharge_to_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to determine where the patient was discharged to after a
|
||
visit. This concept is part of the visit domain and can indicate if a
|
||
patient was discharged to home or sent to a long-term care facility, for
|
||
example.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If available, map the discharge_to_source_value to a standard concept in
|
||
the visit domain. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Visit
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
discharge_to_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This information may be called something different in the source data
|
||
but the field is meant to contain a value indicating where a person was
|
||
discharged to after a visit, as in they went home or were moved to
|
||
long-term care. Typically this applies only to visits that have a length
|
||
of stay of a day or more.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
preceding_visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to find the visit that occurred for the person prior to
|
||
the given visit. There could be a few days or a few years in between.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field can be used to link a visit immediately preceding the current
|
||
visit. Note this is not symmetrical, and there is no such thing as a
|
||
“following_visit_id”.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_OCCURRENCE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this to identify unique interactions between a person and the health
|
||
care system. This identifier links across the other CDM event tables to
|
||
associate events with a visit detail.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This should be populated by creating a unique identifier for each unique
|
||
interaction between a person and the healthcare system where the person
|
||
receives a medical good or service over a span of time.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field contains a concept id representing the kind of visit detail,
|
||
like inpatient or outpatient. All concepts in this field should be
|
||
standard and belong to the Visit domain.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Populate this field based on the kind of visit that took place for the
|
||
person. For example this could be “Inpatient Visit”, “Outpatient Visit”,
|
||
“Ambulatory Visit”, etc. This table will contain standard concepts in
|
||
the Visit domain. These concepts are arranged in a hierarchical
|
||
structure to facilitate cohort definitions by rolling up to generally
|
||
familiar Visits adopted in most healthcare systems worldwide. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Visit
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the date of the start of the encounter. This may or may not be
|
||
equal to the date of the Visit the Visit Detail is associated with.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
When populating VISIT_DETAIL_START_DATE, you should think about the
|
||
patient experience to make decisions on how to define visits. Most
|
||
likely this should be the date of the patient-provider interaction.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_start_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If no time is given for the start date of a visit, set it to midnight
|
||
(00:00:0000).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This the end date of the patient-provider interaction.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Visit Detail end dates are mandatory. If end dates are not provided in
|
||
the source there are three ways in which to derive them:<br> -
|
||
Outpatient Visit Detail: visit_detail_end_datetime =
|
||
visit_detail_start_datetime - Emergency Room Visit Detail:
|
||
visit_detail_end_datetime = visit_detail_start_datetime - Inpatient
|
||
Visit Detail: Usually there is information about discharge. If not, you
|
||
should be able to derive the end date from the sudden decline of
|
||
activity or from the absence of inpatient procedures/drugs. -
|
||
Non-hospital institution Visit Details: Particularly for claims data, if
|
||
end dates are not provided assume the visit is for the duration of month
|
||
that it occurs.<br> For Inpatient Visit Details ongoing at the date of
|
||
ETL, put date of processing the data into visit_detai_end_datetime and
|
||
visit_detail_type_concept_id with 32220 “Still patient” to identify the
|
||
visit as incomplete. All other Visits Details: visit_detail_end_datetime
|
||
= visit_detail_start_datetime.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_end_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If no time is given for the end date of a visit, set it to midnight
|
||
(00:00:0000).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to understand the provenance of the visit detail record,
|
||
or where the record comes from.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Populate this field based on the provenance of the visit detail record,
|
||
as in whether it came from an EHR record or billing claim. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
There will only be one provider per <strong>visit</strong> record and
|
||
the ETL document should clearly state how they were chosen (attending,
|
||
admitting, etc.). This is a typical reason for leveraging the
|
||
VISIT_DETAIL table as even though each VISIT_DETAIL record can only have
|
||
one provider, there is no limit to the number of VISIT_DETAIL records
|
||
that can be associated to a VISIT_OCCURRENCE record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The additional providers associated to a Visit can be stored in this
|
||
table where each VISIT_DETAIL record represents a different provider.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
care_site_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field provides information about the Care Site where the Visit
|
||
Detail took place.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
There should only be one Care Site associated with a Visit Detail.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CARE_SITE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the kind of visit detail that took place (inpatient, outpatient,
|
||
emergency, etc.)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If there is information about the kind of visit detail in the source
|
||
data that value should be stored here. If a visit is an amalgamation of
|
||
visits from the source then use a hierarchy to choose the
|
||
VISIT_DETAIL_SOURCE_VALUE, such as IP -> ER-> OP. This should line
|
||
up with the logic chosen to determine how visits are created.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an
|
||
OMOP supported vocabulary put the concept id representing the source
|
||
value here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
admitting_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This information may be called something different in the source data
|
||
but the field is meant to contain a value indicating where a person was
|
||
admitted from. Typically this applies only to visits that have a length
|
||
of stay, like inpatient visits or long-term care visits.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
admitting_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to determine where the patient was admitted from. This
|
||
concept is part of the visit domain and can indicate if a patient was
|
||
admitted to the hospital from a long-term care facility, for example.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If available, map the admitted_from_source_value to a standard concept
|
||
in the visit domain. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Visit
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
discharge_to_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This information may be called something different in the source data
|
||
but the field is meant to contain a value indicating where a person was
|
||
discharged to after a visit, as in they went home or were moved to
|
||
long-term care. Typically this applies only to visits that have a length
|
||
of stay of a day or more.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
discharge_to_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to determine where the patient was discharged to after a
|
||
visit detail record. This concept is part of the visit domain and can
|
||
indicate if a patient was discharged to home or sent to a long-term care
|
||
facility, for example.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in
|
||
the Visit domain. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Visit
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
preceding_visit_detail_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to find the visit detail that occurred for the person
|
||
prior to the given visit detail record. There could be a few days or a
|
||
few years in between.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately
|
||
preceding the current Visit Detail. Note this is not symmetrical, and
|
||
there is no such thing as a “following_visit_id”.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_DETAIL
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_parent_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to find the visit detail that subsumes the given visit
|
||
detail record. This is used in the case that a visit detail record needs
|
||
to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If there are multiple nested levels to how Visits are represented in the
|
||
source, the VISIT_DETAIL_PARENT_ID can be used to record this
|
||
relationship.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_DETAIL
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to link the VISIT_DETAIL record to its VISIT_OCCURRENCE.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the VISIT_OCCURRENCE_ID that subsumes the VISIT_DETAIL record here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_OCCURRENCE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The unique key given to a condition record for a person. Refer to the
|
||
ETL for how duplicate conditions during the same visit were handled.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Each instance of a condition present in the source data should be
|
||
assigned this unique key. In some cases, a person can have multiple
|
||
records of the same condition within the same visit. It is valid to keep
|
||
these duplicates and assign them individual, unique,
|
||
CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be
|
||
handled.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The PERSON_ID of the PERSON for whom the condition is recorded.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The CONDITION_CONCEPT_ID field is recommended for primary use in
|
||
analyses, and must be used for network studies. This is the standard
|
||
concept mapped from the source value which represents a condition
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records
|
||
whose source values map to concepts with a domain of “Condition” should
|
||
go in this table. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Condition&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Condition
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this date to determine the start date of the condition
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Most often data sources do not have the idea of a start date for a
|
||
condition. Rather, if a source only has one date associated with a
|
||
condition record it is acceptable to use that date for both the
|
||
CONDITION_START_DATE and the CONDITION_END_DATE.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_start_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If a source does not specify datetime the convention is to set the time
|
||
to midnight (00:00:0000)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this date to determine the end date of the condition
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Most often data sources do not have the idea of a start date for a
|
||
condition. Rather, if a source only has one date associated with a
|
||
condition record it is acceptable to use that date for both the
|
||
CONDITION_START_DATE and the CONDITION_END_DATE.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_end_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If a source does not specify datetime the convention is to set the time
|
||
to midnight (00:00:0000)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field can be used to determine the provenance of the Condition
|
||
record, as in whether the condition was from an EHR system, insurance
|
||
claim, registry, or other sources.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance
|
||
of the record. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_status_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This concept represents the point during the visit the diagnosis was
|
||
given (admitting diagnosis, final diagnosis), whether the diagnosis was
|
||
determined due to laboratory findings, if the diagnosis was
|
||
exclusionary, or if it was a preliminary diagnosis, among others.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Choose the Concept in the Condition Status domain that best represents
|
||
the point during the visit when the diagnosis was given. These can
|
||
include admitting diagnosis, principal diagnosis, and secondary
|
||
diagnosis. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Condition Status
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
stop_reason
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Stop Reason indicates why a Condition is no longer valid with
|
||
respect to the purpose within the source data. Note that a Stop Reason
|
||
does not necessarily imply that the condition is no longer occurring.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This information is often not populated in source data and it is a valid
|
||
etl choice to leave it blank if the information does not exist.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(20)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The provider associated with condition record, e.g. the provider who
|
||
made the diagnosis or the provider who recorded the symptom.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The ETL may need to make a choice as to which PROVIDER_ID to put here.
|
||
Based on what is available this may or may not be different than the
|
||
provider associated with the overall VISIT_OCCURRENCE record, for
|
||
example the admitting vs attending physician on an EHR record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The visit during which the condition occurred.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Depending on the structure of the source data, this may have to be
|
||
determined based on dates. If a CONDITION_START_DATE occurs within the
|
||
start and end date of a Visit it is a valid ETL choice to choose the
|
||
VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not
|
||
explicitly stated in the data. While not required, an attempt should be
|
||
made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE
|
||
record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_OCCURRENCE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The VISIT_DETAIL record during which the condition occurred. For
|
||
example, if the person was in the ICU at the time of the diagnosis the
|
||
VISIT_OCCURRENCE record would reflect the overall hospital stay and the
|
||
VISIT_DETAIL record would reflect the ICU stay during the hospital
|
||
visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Same rules apply as for the VISIT_OCCURRENCE_ID.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_DETAIL
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the condition that occurred. For example, this could be an ICD10 or Read
|
||
code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This code is mapped to a Standard Condition Concept in the Standardized
|
||
Vocabularies and the original code is stored here for reference.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the concept representing the condition source value and may not
|
||
necessarily be standard. This field is discouraged from use in analysis
|
||
because it is not required to contain Standard Concepts that are used
|
||
across the OHDSI community, and should only be used when Standard
|
||
Concepts do not adequately represent the source detail for the Condition
|
||
necessary for a given analytic use case. Consider using
|
||
CONDITION_CONCEPT_ID instead to enable standardized analytics that can
|
||
be consistent across the network.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP
|
||
supported vocabulary put the concept id representing the source value
|
||
here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_status_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the condition status.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This information may be called something different in the source data
|
||
but the field is meant to contain a value indicating when and how a
|
||
diagnosis was given to a patient. This source value is mapped to a
|
||
standard concept which is stored in the CONDITION_STATUS_CONCEPT_ID
|
||
field.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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.<br><br>For detailed
|
||
conventions on how to populate this table, please refer to the <a
|
||
href="https://ohdsi.github.io/Themis/drug_exposure.html">THEMIS
|
||
repository</a>.</p>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_exposure_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The unique key given to records of drug dispensings or administrations
|
||
for a person. Refer to the ETL for how duplicate drugs during the same
|
||
visit were handled.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Each instance of a drug dispensing or administration present in the
|
||
source data should be assigned this unique key. In some cases, a person
|
||
can have multiple records of the same drug within the same visit. It is
|
||
valid to keep these duplicates and assign them individual, unique,
|
||
DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be
|
||
handled.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The PERSON_ID of the PERSON for whom the drug dispensing or
|
||
administration is recorded. This may be a system generated code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The DRUG_CONCEPT_ID field is recommended for primary use in analyses,
|
||
and must be used for network studies. This is the standard concept
|
||
mapped from the source concept id which represents a drug product or
|
||
molecule otherwise introduced to the body. The drug concepts can have a
|
||
varying degree of information about drug strength and dose. This
|
||
information is relevant in the context of quantity and administration
|
||
information in the subsequent fields plus strength information from the
|
||
DRUG_STRENGTH table, provided as part of the standard vocabulary
|
||
download.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should
|
||
be derived either from mapping from the source concept id or by picking
|
||
the drug concept representing the most amount of detail you have.
|
||
Records whose source values map to standard concepts with a domain of
|
||
Drug should go in this table. When the Drug Source Value of the code
|
||
cannot be translated into Standard Drug Concept IDs, a Drug exposure
|
||
entry is stored with only the corresponding SOURCE_CONCEPT_ID and
|
||
DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the
|
||
most detailed content of information is preferred during the mapping
|
||
process. These are indicated in the CONCEPT_CLASS_ID field of the
|
||
Concept and are recorded in the following order of precedence:
|
||
<d2>Marketed Product<d3>, <d2>Branded Pack<d3>, <d2>Clinical Pack<d3>,
|
||
<d2>Branded Drug<d3>, <d2>Clinical Drug<d3>, <d2>Branded Drug
|
||
Component<d3>, <d2>Clinical Drug Component<d3>, <d2>Branded Drug
|
||
Form<d3>, <d2>Clinical Drug Form<d3>, and only if no other information
|
||
is available <d2>Ingredient<d3>. Note: If only the drug class is known,
|
||
the DRUG_CONCEPT_ID field should contain 0. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Drug&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2>
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Drug
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_exposure_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this date to determine the start date of the drug record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Valid entries include a start date of a prescription, the date a
|
||
prescription was filled, or the date on which a Drug administration was
|
||
recorded. It is a valid ETL choice to use the date the drug was ordered
|
||
as the DRUG_EXPOSURE_START_DATE.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_exposure_start_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is not required, though it is in v6. If a source does not specify
|
||
datetime the convention is to set the time to midnight (00:00:0000)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_exposure_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for
|
||
the patient.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If this information is not explicitly available in the data, infer the
|
||
end date using the following methods:<br><br> 1. Start first with
|
||
duration or days supply using the calculation drug start date + days
|
||
supply -1 day. 2. Use quantity divided by daily dose that you may obtain
|
||
from the sig or a source field (or assumed daily dose of 1) for solid,
|
||
indivisibile, drug products. If quantity represents ingredient amount,
|
||
quantity divided by daily dose * concentration (from drug_strength) drug
|
||
concept id tells you the dose form. 3. If it is an administration
|
||
record, set drug end date equal to drug start date. If the record is a
|
||
written prescription then set end date to start date + 29. If the record
|
||
is a mail-order prescription set end date to start date + 89. The end
|
||
date must be equal to or greater than the start date. Ibuprofen 20mg/mL
|
||
oral solution concept tells us this is oral solution. Calculate duration
|
||
as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL)
|
||
200*5/20 = 50 days. <a
|
||
href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples
|
||
by dose form</a><br><br>For detailed conventions for how to populate
|
||
this field, please see the <a
|
||
href="https://ohdsi.github.io/Themis/tag_drug_exposure.html">THEMIS
|
||
repository</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_exposure_end_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is not required, though it is in v6. If a source does not specify
|
||
datetime the convention is to set the time to midnight (00:00:0000)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
verbatim_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the end date of the drug exposure as it appears in the source
|
||
data, if it is given
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the end date or discontinuation date as it appears from the source
|
||
data or leave blank if unavailable.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
You can use the TYPE_CONCEPT_ID to delineate between prescriptions
|
||
written vs. prescriptions dispensed vs. medication history
|
||
vs. patient-reported exposure, etc.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Choose the drug_type_concept_id that best represents the provenance of
|
||
the record, for example whether it came from a record of a prescription
|
||
written or physician administered drug. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
stop_reason
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The reason a person stopped a medication as it is represented in the
|
||
source. Reasons include regimen completed, changed, removed, etc. This
|
||
field will be retired in v6.0.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This information is often not populated in source data and it is a valid
|
||
etl choice to leave it blank if the information does not exist.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(20)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
refills
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is only filled in when the record is coming from a prescription
|
||
written this field is meant to represent intended refills at time of the
|
||
prescription.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
quantity
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
To find the dose form of a drug the RELATIONSHIP table can be used where
|
||
the relationship_id is ‘Has dose form’. If liquid, quantity stands for
|
||
the total amount dispensed or ordered of ingredient in the units given
|
||
by the drug_strength table. If the unit from the source data does not
|
||
align with the unit in the DRUG_STRENGTH table the quantity should be
|
||
converted to the correct unit given in DRUG_STRENGTH. For clinical drugs
|
||
with fixed dose forms (tablets etc.) the quantity is the number of
|
||
units/tablets/capsules prescribed or dispensed (can be partial, but then
|
||
only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms
|
||
(injections) the quantity is the amount of ingredient the patient got.
|
||
For example, if the injection is 2mg/mL but the patient got 80mL then
|
||
quantity is reported as 160. Quantified clinical drugs with divisible
|
||
dose forms (prefilled syringes), the quantity is the amount of
|
||
ingredient similar to clinical drugs. Please see <a
|
||
href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to
|
||
calculate drug dose</a> for more information.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
days_supply
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The number of days of supply of the medication as recorded in the
|
||
original prescription or dispensing record. Days supply can differ from
|
||
actual drug duration (i.e. prescribed days supply vs actual exposure).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The field should be left empty if the source data does not contain a
|
||
verbatim days_supply, and should not be calculated from other
|
||
fields.<br><br>Negative values are not allowed. If the source has
|
||
negative days supply the record should be dropped as it is unknown if
|
||
the patient actually took the drug. Several actions are possible: 1)
|
||
record is not trustworthy and we remove the record entirely. 2) we trust
|
||
the record and leave days_supply empty or 3) record needs to be combined
|
||
with other record (e.g. reversal of prescription). High values (>365
|
||
days) should be investigated. If considered an error in the source data
|
||
(e.g. typo), the value needs to be excluded to prevent creation of
|
||
unrealistic long eras.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
sig
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the verbatim instruction for the drug as written by the
|
||
provider.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the written out instructions for the drug as it is verbatim in the
|
||
source, if available.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(MAX)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
route_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route
|
||
domain.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Route
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
lot_number
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Provider associated with drug record, e.g. the provider who wrote
|
||
the prescription or the provider who administered the drug.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The ETL may need to make a choice as to which PROVIDER_ID to put here.
|
||
Based on what is available this may or may not be different than the
|
||
provider associated with the overall VISIT_OCCURRENCE record, for
|
||
example the ordering vs administering physician on an EHR record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Visit during which the drug was prescribed, administered or
|
||
dispensed.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
To populate this field drug exposures must be explicitly initiated in
|
||
the visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_OCCURRENCE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The VISIT_DETAIL record during which the drug exposure occurred. For
|
||
example, if the person was in the ICU at the time of the drug
|
||
administration the VISIT_OCCURRENCE record would reflect the overall
|
||
hospital stay and the VISIT_DETAIL record would reflect the ICU stay
|
||
during the hospital visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Same rules apply as for the VISIT_OCCURRENCE_ID.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_DETAIL
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the drug exposure that occurred. For example, this could be an NDC or
|
||
Gemscript code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This code is mapped to a Standard Drug Concept in the Standardized
|
||
Vocabularies and the original code is stored here for reference.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the concept representing the drug source value and may not
|
||
necessarily be standard. This field is discouraged from use in analysis
|
||
because it is not required to contain Standard Concepts that are used
|
||
across the OHDSI community, and should only be used when Standard
|
||
Concepts do not adequately represent the source detail for the Drug
|
||
necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID
|
||
instead to enable standardized analytics that can be consistent across
|
||
the network.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP
|
||
supported vocabulary put the concept id representing the source value
|
||
here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
route_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the drug route.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This information may be called something different in the source data
|
||
but the field is meant to contain a value indicating when and how a drug
|
||
was given to a patient. This source value is mapped to a standard
|
||
concept which is stored in the ROUTE_CONCEPT_ID field.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
dose_unit_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the dose unit of the drug given.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This information may be called something different in the source data
|
||
but the field is meant to contain a value indicating the unit of dosage
|
||
of drug given to the patient. This is an older column and will be
|
||
deprecated in an upcoming version.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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 24 hours, then it should be recorded
|
||
as a separate record for each day the procedure occurred, this logic is
|
||
in lieu of the PROCEDURE_END_DATE, which will be added in a future
|
||
version of the CDM. When dealing with duplicate records, the ETL must
|
||
determine whether to sum them up into one record or keep them separate.
|
||
Things to consider are: - Same Procedure - Same PROCEDURE_DATETIME -
|
||
Same Visit Occurrence or Visit Detail - Same Provider - Same Modifier
|
||
for Procedures. Source codes and source text fields mapped to Standard
|
||
Concepts of the Procedure Domain have to be recorded here.</p>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
procedure_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The unique key given to a procedure record for a person. Refer to the
|
||
ETL for how duplicate procedures during the same visit were handled.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Each instance of a procedure occurrence in the source data should be
|
||
assigned this unique key. In some cases, a person can have multiple
|
||
records of the same procedure within the same visit. It is valid to keep
|
||
these duplicates and assign them individual, unique,
|
||
PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be
|
||
handled.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The PERSON_ID of the PERSON for whom the procedure is recorded. This may
|
||
be a system generated code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
procedure_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The PROCEDURE_CONCEPT_ID field is recommended for primary use in
|
||
analyses, and must be used for network studies. This is the standard
|
||
concept mapped from the source value which represents a procedure
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records
|
||
whose source values map to standard concepts with a domain of
|
||
“Procedure” should go in this table. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Procedure&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Procedure
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
procedure_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this date to determine the date the procedure occurred.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If a procedure lasts more than a day, then it should be recorded as a
|
||
separate record for each day the procedure occurred, this logic is in
|
||
lieu of the procedure_end_date, which will be added in a future version
|
||
of the CDM.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
procedure_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is not required, though it is in v6. If a source does not specify
|
||
datetime the convention is to set the time to midnight (00:00:0000)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
procedure_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field can be used to determine the provenance of the Procedure
|
||
record, as in whether the procedure was from an EHR system, insurance
|
||
claim, registry, or other sources.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance
|
||
of the record, for example whether it came from an EHR record or billing
|
||
claim. If a procedure is recorded as an EHR encounter, the
|
||
PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
modifier_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The modifiers are intended to give additional information about the
|
||
procedure but as of now the vocabulary is under review.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
It is up to the ETL to choose how to map modifiers if they exist in
|
||
source data. These concepts are typically distinguished by ‘Modifier’
|
||
concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’
|
||
vocabulary). If there is more than one modifier on a record, one should
|
||
be chosen that pertains to the procedure rather than provider. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?conceptClass=CPT4+Modifier&conceptClass=HCPCS+Modifier&vocabulary=CPT4&vocabulary=HCPCS&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
quantity
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the quantity value is omitted, a single procedure is assumed.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If a Procedure has a quantity of ‘0’ in the source, this should default
|
||
to ‘1’ in the ETL. If there is a record in the source it can be assumed
|
||
the exposure occurred at least once
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The provider associated with the procedure record, e.g. the provider who
|
||
performed the Procedure.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The ETL may need to make a choice as to which PROVIDER_ID to put here.
|
||
Based on what is available this may or may not be different than the
|
||
provider associated with the overall VISIT_OCCURRENCE record, for
|
||
example the admitting vs attending physician on an EHR record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The visit during which the procedure occurred.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Depending on the structure of the source data, this may have to be
|
||
determined based on dates. If a PROCEDURE_DATE occurs within the start
|
||
and end date of a Visit it is a valid ETL choice to choose the
|
||
VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not
|
||
explicitly stated in the data. While not required, an attempt should be
|
||
made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE
|
||
record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_OCCURRENCE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The VISIT_DETAIL record during which the Procedure occurred. For
|
||
example, if the Person was in the ICU at the time of the Procedure the
|
||
VISIT_OCCURRENCE record would reflect the overall hospital stay and the
|
||
VISIT_DETAIL record would reflect the ICU stay during the hospital
|
||
visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Same rules apply as for the VISIT_OCCURRENCE_ID.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_DETAIL
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
procedure_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the procedure that occurred. For example, this could be an CPT4 or OPCS4
|
||
code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this value to look up the source concept id and then map the source
|
||
concept id to a standard concept id.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
procedure_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the concept representing the procedure source value and may not
|
||
necessarily be standard. This field is discouraged from use in analysis
|
||
because it is not required to contain Standard Concepts that are used
|
||
across the OHDSI community, and should only be used when Standard
|
||
Concepts do not adequately represent the source detail for the Procedure
|
||
necessary for a given analytic use case. Consider using
|
||
PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can
|
||
be consistent across the network.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP
|
||
supported vocabulary put the concept id representing the source value
|
||
here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
modifier_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The original modifier code from the source is stored here for reference.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
device_exposure_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The unique key given to records a person’s exposure to a foreign
|
||
physical object or instrument.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Each instance of an exposure to a foreign object or device present in
|
||
the source data should be assigned this unique key.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
device_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The DEVICE_CONCEPT_ID field is recommended for primary use in analyses,
|
||
and must be used for network studies. This is the standard concept
|
||
mapped from the source concept id which represents a foreign object or
|
||
instrument the person was exposed to.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The CONCEPT_ID that the DEVICE_SOURCE_VALUE maps to.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Device
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
device_exposure_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this date to determine the start date of the device record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Valid entries include a start date of a procedure to implant a device,
|
||
the date of a prescription for a device, or the date of device
|
||
administration.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
device_exposure_start_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is not required, though it is in v6. If a source does not specify
|
||
datetime the convention is to set the time to midnight (00:00:0000)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
device_exposure_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended
|
||
for the patient, if given.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the end date or discontinuation date as it appears from the source
|
||
data or leave blank if unavailable.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
device_exposure_end_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If a source does not specify datetime the convention is to set the time
|
||
to midnight (00:00:0000)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
device_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
You can use the TYPE_CONCEPT_ID to denote the provenance of the record,
|
||
as in whether the record is from administrative claims or EHR.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Choose the drug_type_concept_id that best represents the provenance of
|
||
the record, for example whether it came from a record of a prescription
|
||
written or physician administered drug. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
unique_device_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the Unique Device Identification number for devices regulated by
|
||
the FDA, if given.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
For medical devices that are regulated by the FDA, a Unique Device
|
||
Identification (UDI) is provided if available in the data source and is
|
||
recorded in the UNIQUE_DEVICE_ID field.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
quantity
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Provider associated with device record, e.g. the provider who wrote
|
||
the prescription or the provider who implanted the device.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The ETL may need to make a choice as to which PROVIDER_ID to put here.
|
||
Based on what is available this may or may not be different than the
|
||
provider associated with the overall VISIT_OCCURRENCE record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Visit during which the device was prescribed or given.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
To populate this field device exposures must be explicitly initiated in
|
||
the visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_OCCURRENCE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Visit Detail during which the device was prescribed or given.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
To populate this field device exposures must be explicitly initiated in
|
||
the visit detail record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_DETAIL
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
device_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the device exposure that occurred. For example, this could be an NDC or
|
||
Gemscript code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This code is mapped to a Standard Device Concept in the Standardized
|
||
Vocabularies and the original code is stored here for reference.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
device_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the concept representing the device source value and may not
|
||
necessarily be standard. This field is discouraged from use in analysis
|
||
because it is not required to contain Standard Concepts that are used
|
||
across the OHDSI community, and should only be used when Standard
|
||
Concepts do not adequately represent the source detail for the Device
|
||
necessary for a given analytic use case. Consider using
|
||
DEVICE_CONCEPT_ID instead to enable standardized analytics that can be
|
||
consistent across the network.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the DEVICE_SOURCE_VALUE is coded in the source data using an OMOP
|
||
supported vocabulary put the concept id representing the source value
|
||
here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
measurement_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The unique key given to a Measurement record for a Person. Refer to the
|
||
ETL for how duplicate Measurements during the same Visit were handled.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Each instance of a measurement present in the source data should be
|
||
assigned this unique key. In some cases, a person can have multiple
|
||
records of the same measurement within the same visit. It is valid to
|
||
keep these duplicates and assign them individual, unique,
|
||
MEASUREMENT_IDs, though it is up to the ETL how they should be handled.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The PERSON_ID of the Person for whom the Measurement is recorded. This
|
||
may be a system generated code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
measurement_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The MEASUREMENT_CONCEPT_ID field is recommended for primary use in
|
||
analyses, and must be used for network studies. This is the standard
|
||
concept mapped from the source value which represents a measurement.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The CONCEPT_ID that the MEASUREMENT_SOURCE_VALUE maps to. Only records
|
||
whose source values map to concepts with a domain of <d2>Measurement<d3>
|
||
should go in this table. </d3></d2>
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Measurement
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
measurement_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this date to determine the date of the measurement.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If there are multiple dates in the source data associated with a record
|
||
such as order_date, draw_date, and result_date, choose the one that is
|
||
closest to the date the sample was drawn from the patient.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
measurement_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is not required, though it is in v6. If a source does not specify
|
||
datetime the convention is to set the time to midnight (00:00:0000)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
measurement_time
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is present for backwards compatibility and will be deprecated in an
|
||
upcoming version.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(10)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
measurement_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field can be used to determine the provenance of the Measurement
|
||
record, as in whether the measurement was from an EHR system, insurance
|
||
claim, registry, or other sources.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the
|
||
provenance of the record, for example whether it came from an EHR record
|
||
or billing claim. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
operator_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The meaning of Concept <a
|
||
href="https://athena.ohdsi.org/search-terms/terms/4172703">4172703</a>
|
||
for ‘=’ is identical to omission of a OPERATOR_CONCEPT_ID value. Since
|
||
the use of this field is rare, it’s important when devising analyses to
|
||
not to forget testing for the content of this field for values different
|
||
from =.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Operators are =, > and these concepts belong to the ‘Meas Value
|
||
Operator’ domain. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>. Leave it NULL if there’s an exact numeric value given
|
||
(instead of putting ‘=’) or there’s no numeric value at all.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
value_as_number
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the numerical value of the Result of the Measurement, if
|
||
available. Note that measurements such as blood pressures will be split
|
||
into their component parts i.e. one record for systolic, one record for
|
||
diastolic.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
<a
|
||
href="https://ohdsi.github.io/Themis/negative_value_as_number.html">Convention
|
||
for negative values</a>
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
value_as_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the raw data gives a categorial result for measurements those values
|
||
are captured and mapped to standard concepts in the ‘Meas Value’ domain.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the raw data provides categorial results as well as continuous
|
||
results for measurements, it is a valid ETL choice to preserve both
|
||
values. The continuous value should go in the VALUE_AS_NUMBER field and
|
||
the categorical value should be mapped to a standard concept in the
|
||
‘Meas Value’ domain and put in the VALUE_AS_CONCEPT_ID field. This is
|
||
also the destination for the ‘Maps to value’ relationship. If there’s no
|
||
categorial result in a source_data, set value_as_concept_id to NULL, if
|
||
there is a categorial result in a source_data but without mapping, set
|
||
value_as_concept_id to 0.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
unit_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
At present, there isn’t a prescribed unit for individual measurements,
|
||
such as Hemoglobin A1C, meaning it’s not obligatory to express these
|
||
measurements as a percentage. UNIT_SOURCE_VALUES should be linked to a
|
||
Standard Concept within the Unit domain that most accurately reflects
|
||
the unit provided in the source data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data does not include units, set UNIT_CONCEPT_ID to NULL.
|
||
If units are provided but not mapped, set UNIT_CONCEPT_ID to 0.
|
||
Otherwise, map the units to a CONCEPT_ID. Remember that units are
|
||
case-sensitive in vocabulary.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Unit
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
range_low
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are
|
||
provided by the source and should remain NULL if not given.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If reference ranges for upper and lower limit of normal as provided
|
||
(typically by a laboratory) these are stored in the RANGE_HIGH and
|
||
RANGE_LOW fields. This should be set to NULL if not provided.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
range_high
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are
|
||
provided by the source and should remain NULL if not given.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If reference ranges for upper and lower limit of normal as provided
|
||
(typically by a laboratory) these are stored in the RANGE_HIGH and
|
||
RANGE_LOW fields. This should be set to NULL if not provided.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The provider associated with measurement record, e.g. the provider who
|
||
ordered the test or the provider who recorded the result.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The ETL may need to make a choice as to which PROVIDER_ID to put here.
|
||
Based on what is available this may or may not be different than the
|
||
provider associated with the overall VISIT_OCCURRENCE record. For
|
||
example the admitting vs attending physician on an EHR record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The visit during which the Measurement occurred.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Depending on the structure of the source data, this may have to be
|
||
determined based on dates. If a MEASUREMENT_DATE occurs within the start
|
||
and end date of a Visit it is a valid ETL choice to choose the
|
||
VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not
|
||
explicitly stated in the data. While not required, an attempt should be
|
||
made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a
|
||
measurement is related to a visit explicitly in the source data, it is
|
||
possible that the result date of the Measurement falls outside of the
|
||
bounds of the Visit dates.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_OCCURRENCE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The VISIT_DETAIL record during which the Measurement occurred. For
|
||
example, if the Person was in the ICU at the time the VISIT_OCCURRENCE
|
||
record would reflect the overall hospital stay and the VISIT_DETAIL
|
||
record would reflect the ICU stay during the hospital visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Same rules apply as for the VISIT_OCCURRENCE_ID.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_DETAIL
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
measurement_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the Measurement that occurred. For example, this could be an ICD10 or
|
||
Read code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This code is mapped to a Standard Measurement Concept in the
|
||
Standardized Vocabularies and the original code is stored here for
|
||
reference.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
measurement_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the concept representing the MEASUREMENT_SOURCE_VALUE and may
|
||
not necessarily be standard. This field is discouraged from use in
|
||
analysis because it is not required to contain Standard Concepts that
|
||
are used across the OHDSI community, and should only be used when
|
||
Standard Concepts do not adequately represent the source detail for the
|
||
Measurement necessary for a given analytic use case. Consider using
|
||
MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can
|
||
be consistent across the network.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the MEASUREMENT_SOURCE_VALUE is coded in the source data using an
|
||
OMOP supported vocabulary put the concept id representing the source
|
||
value here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
unit_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field contains the exact value from the source data that represents
|
||
the unit of measurement used.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This value corresponds to a standardized CONCEPT_ID found in
|
||
UNIT_CONCEPT_ID and in the ‘Unit’ domain within the Standardized
|
||
Vocabularies. The original code is retained here for reference purposes.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
value_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim result value of the Measurement from the
|
||
source data .
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If both a continuous and categorical result are given in the source data
|
||
such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both
|
||
included, store the verbatim value that was mapped to
|
||
VALUE_AS_CONCEPT_ID here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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.</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 but they must not belong to the Condition,
|
||
Procedure, Drug, Device, Specimen, or Measurement domains and they must
|
||
be Standard Concepts. <br><br>The observation table usually records the
|
||
date or datetime of when the observation was obtained, not the date of
|
||
the observation starting. For example, if the patient reports that they
|
||
had a heart attack when they were 50, the observation date or datetime
|
||
is the date of the report, the heart attack observation can have a
|
||
value_as_concept which captures how long ago the observation applied to
|
||
the patient.</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>Records whose Source Values map to any domain besides Condition,
|
||
Procedure, Drug, Specimen, Measurement or Device should be stored in the
|
||
Observation table. Observations can be stored as attribute value pairs,
|
||
with the attribute as the Observation Concept and the value representing
|
||
the clinical fact. This fact can be a Concept (stored in
|
||
VALUE_AS_CONCEPT), a numerical value (VALUE_AS_NUMBER), a verbatim
|
||
string (VALUE_AS_STRING), or a datetime (VALUE_AS_DATETIME). Even though
|
||
Observations do not have an explicit result, the clinical fact can be
|
||
stated separately from the type of Observation in the VALUE_AS_* fields.
|
||
It is recommended for Observations that are suggestive statements of
|
||
positive assertion should have a value of ‘Yes’ (concept_id=4188539),
|
||
recorded, even though the null value is the equivalent.</p>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The unique key given to an Observation record for a Person. Refer to the
|
||
ETL for how duplicate Observations during the same Visit were handled.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Each instance of an observation present in the source data should be
|
||
assigned this unique key.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The PERSON_ID of the Person for whom the Observation is recorded. This
|
||
may be a system generated code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The OBSERVATION_CONCEPT_ID field is recommended for primary use in
|
||
analyses, and must be used for network studies.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is
|
||
no specified domain that the Concepts in this table must adhere to. The
|
||
only rule is that records with Concepts in the Condition, Procedure,
|
||
Drug, Measurement, or Device domains MUST go to the corresponding table.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date of when the Observation was obtained. Depending on what the
|
||
Observation represents this could be the date of a lab test, the date of
|
||
a survey, or the date a patient’s family history was taken.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
For some observations the ETL may need to make a choice as to which date
|
||
to choose.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If no time is given set to midnight (00:00:00).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field can be used to determine the provenance of the Observation
|
||
record, as in whether the measurement was from an EHR system, insurance
|
||
claim, registry, or other sources.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the
|
||
provenance of the record, for example whether it came from an EHR record
|
||
or billing claim. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
value_as_number
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the numerical value of the Result of the Observation, if
|
||
applicable and available. It is not expected that all Observations will
|
||
have numeric results, rather, this field is here to house values should
|
||
they exist.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
value_as_string
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the categorical value of the Result of the Observation, if
|
||
applicable and available.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(60)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
value_as_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
It is possible that some records destined for the Observation table have
|
||
two clinical ideas represented in one source code. This is common with
|
||
ICD10 codes that describe a family history of some Condition, for
|
||
example. In OMOP the Vocabulary breaks these two clinical ideas into two
|
||
codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the
|
||
VALUE_AS_CONCEPT_ID. It is important when using the Observation table to
|
||
keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID
|
||
field for relevant information.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Note that the value of VALUE_AS_CONCEPT_ID may be provided through
|
||
mapping from a source Concept which contains the content of the
|
||
Observation. In those situations, the CONCEPT_RELATIONSHIP table in
|
||
addition to the ‘Maps to’ record contains a second record with the
|
||
relationship_id set to ‘Maps to value’. For example, ICD10 <a
|
||
href="https://athena.ohdsi.org/search-terms/terms/45581076">Z82.4</a>
|
||
‘Family history of ischaemic heart disease and other diseases of the
|
||
circulatory system’ has a ‘Maps to’ relationship to <a
|
||
href="https://athena.ohdsi.org/search-terms/terms/4167217">4167217</a>
|
||
‘Family history of clinical finding’ as well as a ‘Maps to value’ record
|
||
to <a
|
||
href="https://athena.ohdsi.org/search-terms/terms/134057">134057</a>
|
||
‘Disorder of cardiovascular system’. If there’s no categorial result in
|
||
a source_data, set value_as_concept_id to NULL, if there is a categorial
|
||
result in a source_data but without mapping, set value_as_concept_id to
|
||
0.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
qualifier_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field contains all attributes specifying the clinical fact further,
|
||
such as as degrees, severities, drug-drug interaction alerts etc.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use your best judgement as to what Concepts to use here and if they are
|
||
necessary to accurately represent the clinical record. There is no
|
||
restriction on the domain of these Concepts, they just need to be
|
||
Standard.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
unit_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
There is currently no recommended unit for individual observation
|
||
concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in
|
||
the Unit domain that best represents the unit as given in the source
|
||
data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
There is no standardization requirement for units associated with
|
||
OBSERVATION_CONCEPT_IDs, however, it is the responsibility of the ETL to
|
||
choose the most plausible unit. If the source unit is NULL (applicable
|
||
to cases when there’s no numerical value or when it doesn’t require a
|
||
unit), keep unit_concept_id NULL as well. If there’s no mapping of a
|
||
source unit, populate unit_concept_id with 0.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Unit
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The provider associated with the observation record, e.g. the provider
|
||
who ordered the test or the provider who recorded the result.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The ETL may need to make a choice as to which PROVIDER_ID to put here.
|
||
Based on what is available this may or may not be different than the
|
||
provider associated with the overall VISIT_OCCURRENCE record. For
|
||
example the admitting vs attending physician on an EHR record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The visit during which the Observation occurred.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Depending on the structure of the source data, this may have to be
|
||
determined based on dates. If an OBSERVATION_DATE occurs within the
|
||
start and end date of a Visit it is a valid ETL choice to choose the
|
||
VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not
|
||
explicitly stated in the data. While not required, an attempt should be
|
||
made to locate the VISIT_OCCURRENCE_ID of the observation record. If an
|
||
observation is related to a visit explicitly in the source data, it is
|
||
possible that the result date of the Observation falls outside of the
|
||
bounds of the Visit dates.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_OCCURRENCE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The VISIT_DETAIL record during which the Observation occurred. For
|
||
example, if the Person was in the ICU at the time the VISIT_OCCURRENCE
|
||
record would reflect the overall hospital stay and the VISIT_DETAIL
|
||
record would reflect the ICU stay during the hospital visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Same rules apply as for the VISIT_OCCURRENCE_ID.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_DETAIL
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the Observation that occurred. For example, this could be an ICD10 or
|
||
Read code.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This code is mapped to a Standard Concept in the Standardized
|
||
Vocabularies and the original code is stored here for reference.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
observation_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the concept representing the OBSERVATION_SOURCE_VALUE and may
|
||
not necessarily be standard. This field is discouraged from use in
|
||
analysis because it is not required to contain Standard Concepts that
|
||
are used across the OHDSI community, and should only be used when
|
||
Standard Concepts do not adequately represent the source detail for the
|
||
Observation necessary for a given analytic use case. Consider using
|
||
OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can
|
||
be consistent across the network.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the OBSERVATION_SOURCE_VALUE is coded in the source data using an
|
||
OMOP supported vocabulary put the concept id representing the source
|
||
value here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
unit_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the unit of the Observation that occurred.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This code is mapped to a Standard Condition Concept in the Standardized
|
||
Vocabularies and the original code is stored here for reference.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
qualifier_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field houses the verbatim value from the source data representing
|
||
the qualifier of the Observation that occurred.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This code is mapped to a Standard Condition Concept in the Standardized
|
||
Vocabularies and the original code is stored here for reference.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<div id="death" class="section level3 tabset tabset-pills">
|
||
<h3 class="tabset tabset-pills">death</h3>
|
||
<p><strong>Table Description</strong></p>
|
||
<p>The death domain contains the clinical event for how and when a
|
||
Person dies. A person can have up to one record if the source system
|
||
contains evidence about the Death, such as: Condition in an
|
||
administrative claim, status of enrollment into a health plan, or
|
||
explicit record in EHR data.</p>
|
||
<p><strong>User Guide</strong></p>
|
||
<p>NA</p>
|
||
<p><strong>ETL Conventions</strong></p>
|
||
<p>For specific conventions on how to populate this table, please refer
|
||
to the <a href="https://ohdsi.github.io/Themis/death.html">THEMIS
|
||
repository</a>.</p>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
death_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date the person was deceased.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the precise date include day or month is not known or not allowed,
|
||
December is used as the default month, and the last day of the month the
|
||
default day. For additional conventions related to this field, please
|
||
refer to the <a
|
||
href="https://ohdsi.github.io/Themis/tag_death_date.html">THEMIS
|
||
repository</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
death_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If not available set time to midnight (00:00:00)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
death_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the provenance of the death record, i.e., where it came from. It
|
||
is possible that an administrative claims database would source death
|
||
information from a government file so do not assume the Death Type is
|
||
the same as the Visit Type, etc.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use the type concept that be reflects the source of the death record. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cause_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the Standard Concept representing the Person’s cause of death,
|
||
if available.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
There is no specified domain for this concept, just choose the Standard
|
||
Concept Id that best represents the person’s cause of death.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cause_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If available, put the source code representing the cause of death here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cause_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the cause of death was coded using a Vocabulary present in the OMOP
|
||
Vocabularies (not necessarily a standard concept) put the CONCEPT_ID
|
||
representing the cause of death here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
A unique identifier for each note.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date the note was recorded.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If time is not given set the time to midnight.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The provenance of the note. Most likely this will be EHR.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the source system of the note, as in EHR record. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_class_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
A Standard Concept Id representing the HL7 LOINC Document Type
|
||
Vocabulary classification of the note.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Map the note classification to a Standard Concept. For more information
|
||
see the ETL Conventions in the description of the NOTE table. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&conceptClass=Doc+Kind&conceptClass=Doc+Role&conceptClass=Doc+Setting&conceptClass=Doc+Subject+Matter&conceptClass=Doc+Type+of+Service&domain=Meas+Value&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>. This Concept can alternatively be represented by concepts
|
||
with the relationship ‘Kind of (LOINC)’ to <a
|
||
href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a>
|
||
(Note).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_title
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The title of the note.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(250)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_text
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The content of the note.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(MAX)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
encoding_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the Concept representing the character encoding type.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the Concept Id that represents the encoding character type here.
|
||
Currently the only option is UTF-8 (<a
|
||
href="https://athena.ohdsi.org/search-terms/terms/32678">32678</a>). It
|
||
the note is encoded in any other type, like ASCII then put 0.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
language_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The language of the note.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use Concepts that are descendants of the concept <a
|
||
href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a>
|
||
(World Languages).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Provider who wrote the note.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The ETL may need to make a determination on which provider to put here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PROVIDER
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_occurrence_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Visit during which the note was written.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_OCCURRENCE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
visit_detail_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Visit Detail during which the note was written.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
VISIT_DETAIL
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The source value mapped to the NOTE_CLASS_CONCEPT_ID.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_nlp_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
A unique identifier for the NLP record.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the NOTE_ID for the NOTE record the NLP record is associated to.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
section_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The SECTION_CONCEPT_ID should be used to represent the note section
|
||
contained in the NOTE_NLP record. These concepts can be found as parts
|
||
of document panels and are based on the type of note written, i.e. a
|
||
discharge summary. These panels can be found as concepts with the
|
||
relationship ‘Subsumes’ to CONCEPT_ID <a
|
||
href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
snippet
|
||
</td>
|
||
<td style="text-align:left;">
|
||
A small window of text surrounding the term
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(250)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
“offset”
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Character offset of the extracted term in the input note
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
lexical_variant
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Raw text extracted from the NLP tool.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(250)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_nlp_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
note_nlp_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
nlp_system
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Name and version of the NLP system that extracted the term. Useful for
|
||
data provenance.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(250)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
nlp_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date of the note processing.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
nlp_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date and time of the note processing.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
term_exists
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Term_exists is defined as a flag that indicates if the patient actually
|
||
has or had the condition. Any of the following modifiers would make
|
||
Term_exists false: Negation = true Subject = [anything other than the
|
||
patient] Conditional = true/li> Rule_out = true Uncertain = very low
|
||
certainty or any lower certainties A complete lack of modifiers would
|
||
make Term_exists true.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(1)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
term_temporal
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Term_temporal is to indicate if a condition is present or just in the
|
||
past. The following would be past:<br><br> - History = true -
|
||
Concept_date = anything before the time of the report
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
term_modifiers
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
For the modifiers that are there, they would have to have these
|
||
values:<br><br> - Negation = false - Subject = patient - Conditional =
|
||
false - Rule_out = false - Uncertain = true or high or moderate or even
|
||
low (could argue about low). Term_modifiers will concatenate all
|
||
modifiers for different types of entities (conditions, drugs, labs etc)
|
||
into one string. Lab values will be saved as one of the modifiers.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(2000)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specimen_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Unique identifier for each specimen.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The person from whom the specimen is collected.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specimen_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the
|
||
specimen domain. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specimen_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the source of the specimen record, as in an EHR system. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Type Concept
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specimen_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date the specimen was collected.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specimen_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
quantity
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The amount of specimen collected from the person.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
unit_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The unit for the quantity of the specimen.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>. If the source unit is NULL (applicable to cases when
|
||
there’s no numerical value or when it doesn’t require a unit), keep
|
||
unit_concept_id NULL as well. If there’s no mapping of a source unit,
|
||
populate unit_concept_id with 0.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
anatomic_site_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the site on the body where the specimen is from.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec
|
||
Anatomic Site domain. This should be coded at the lowest level of
|
||
granularity <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Spec+Anatomic+Site&conceptClass=Body+Structure&page=4&pageSize=15&query=">Accepted
|
||
Concepts</a>
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
disease_status_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specimen_source_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the identifier for the specimen from the source system.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specimen_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
unit_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This unit for the quantity of the specimen, as represented in the
|
||
source.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
anatomic_site_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the site on the body where the specimen was taken from, as
|
||
represented in the source.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
disease_status_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
domain_concept_id_1
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
fact_id_1
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
domain_concept_id_2
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
fact_id_2
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
relationship_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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.</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.</p>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
location_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The unique key given to a unique Location.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Each instance of a Location in the source data should be assigned this
|
||
unique key.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
address_1
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the first line of the address.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
address_2
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the second line of the address
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
city
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
state
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(2)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
zip
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Zip codes are handled as strings of up to 9 characters length. For US
|
||
addresses, these represent either a 3-digit abbreviated Zip code as
|
||
provided by many sources for patient protection reasons, the full
|
||
5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons
|
||
analytical methods should expect and utilize only the first 3 digits.
|
||
For international addresses, different rules apply.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(9)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
county
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(20)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
location_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the verbatim value for the location here, as it shows up in the
|
||
source.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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 nature of the
|
||
site - the latter could be the place of service, name, or another
|
||
characteristic in your source data. 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.<br><br>For additional detailed conventions
|
||
on how to populate this table, please refer to <a
|
||
href="https://ohdsi.github.io/Themis/care_site.html">THEMIS
|
||
repository</a>.</p>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
care_site_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Assign an id to each unique combination of location_id and
|
||
place_of_service_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
care_site_name
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The name of the care_site as it appears in the source data
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(255)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
place_of_service_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is a high-level way of characterizing a Care Site. Typically,
|
||
however, Care Sites can provide care in multiple settings (inpatient,
|
||
outpatient, etc.) and this granularity should be reflected in the visit.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Choose the concept in the visit domain that best represents the setting
|
||
in which healthcare is provided in the Care Site. If most visits in a
|
||
Care Site are Inpatient, then the place_of_service_concept_id should
|
||
represent Inpatient. If information is present about a unique Care Site
|
||
(e.g. Pharmacy) then a Care Site record should be created. <a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=2&pageSize=15&query=">Accepted
|
||
Concepts</a>. For information about how to populate this field please
|
||
see the <a
|
||
href="https://ohdsi.github.io/Themis/tag_place_of_service.html">THEMIS
|
||
Conventions</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
location_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The location_id from the LOCATION table representing the physical
|
||
location of the care_site.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
LOCATION
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
care_site_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The identifier of the care_site as it appears in the source data. This
|
||
could be an identifier separate from the name of the care_site.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
place_of_service_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the place of service of the care_site as it appears in the source
|
||
data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
It is assumed that every provider with a different unique identifier is
|
||
in fact a different person and should be treated independently.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This identifier can be the original id from the source data provided it
|
||
is an integer, otherwise it can be an autogenerated number.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_name
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field is not necessary as it is not necessary to have the actual
|
||
identity of the Provider. Rather, the idea is to uniquely and
|
||
anonymously identify providers of care across the database.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(255)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
npi
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the National Provider Number issued to health care providers in
|
||
the US by the Centers for Medicare and Medicaid Services (CMS).
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(20)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
dea
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the identifier issued by the DEA, a US federal agency, that
|
||
allows a provider to write prescriptions for controlled substances.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(20)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specialty_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field either represents the most common specialty that occurs in
|
||
the data or the most specific concept that represents all specialties
|
||
listed, should the provider have more than one. This includes physician
|
||
specialties such as internal medicine, emergency medicine, etc. and
|
||
allied health professionals such as nurses, midwives, and pharmacists.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If a Provider has more than one Specialty, there are two options: 1.
|
||
Choose a concept_id which is a common ancestor to the multiple
|
||
specialties, or, 2. Choose the specialty that occurs most often for the
|
||
provider. Concepts in this field should be Standard with a domain of
|
||
Provider. <a
|
||
href="http://athena.ohdsi.org/search-terms/terms?domain=Provider&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
care_site_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the CARE_SITE_ID for the location that the provider primarily
|
||
practices in.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If a Provider has more than one Care Site, the main or most often
|
||
exerted CARE_SITE_ID should be recorded.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CARE_SITE
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
year_of_birth
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
gender_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field represents the recorded gender of the provider in the source
|
||
data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If given, put a concept from the gender domain representing the recorded
|
||
gender of the provider. <a
|
||
href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Gender
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
provider_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Use this field to link back to providers in the source data. This is
|
||
typically used for error checking of ETL logic.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Some use cases require the ability to link back to providers in the
|
||
source data. This field allows for the storing of the provider
|
||
identifier as it appears in the source.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specialty_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the kind of provider or specialty as it appears in the source
|
||
data. This includes physician specialties such as internal medicine,
|
||
emergency medicine, etc. and allied health professionals such as nurses,
|
||
midwives, and pharmacists.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the kind of provider as it appears in the source data. This field is
|
||
up to the discretion of the ETL-er as to whether this should be the
|
||
coded value from the source or the text description of the lookup value.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
specialty_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is often zero as many sites use proprietary codes to store
|
||
physician speciality.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data codes provider specialty in an OMOP supported
|
||
vocabulary store the concept_id here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
gender_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is provider’s gender as it appears in the source data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Put the provider’s gender as it appears in the source data. This field
|
||
is up to the discretion of the ETL-er as to whether this should be the
|
||
coded value from the source or the text description of the lookup value.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
gender_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is often zero as many sites use proprietary codes to store provider
|
||
gender.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data codes provider gender in an OMOP supported vocabulary
|
||
store the concept_id here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
payer_plan_period_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
A unique identifier for each unique combination of a Person, Payer,
|
||
Plan, and Period of time.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Person covered by the Plan.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD
|
||
records
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
payer_plan_period_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Start date of Plan coverage.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
payer_plan_period_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
End date of Plan coverage.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
payer_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field represents the organization who reimburses the provider which
|
||
administers care to the Person.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Map the Payer directly to a standard CONCEPT_ID. If one does not exists
|
||
please contact the vocabulary team. There is no global controlled
|
||
vocabulary available for this information. The point is to stratify on
|
||
this information and identify if Persons have the same payer, though the
|
||
name of the Payer is not necessary. <a
|
||
href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
payer_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the Payer as it appears in the source data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
payer_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data codes the Payer in an OMOP supported vocabulary store
|
||
the concept_id here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
plan_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field represents the specific health benefit Plan the Person is
|
||
enrolled in.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Map the Plan directly to a standard CONCEPT_ID. If one does not exists
|
||
please contact the vocabulary team. There is no global controlled
|
||
vocabulary available for this information. The point is to stratify on
|
||
this information and identify if Persons have the same health benefit
|
||
Plan though the name of the Plan is not necessary. <a
|
||
href="http://athena.ohdsi.org/search-terms/terms?domain=Plan&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
plan_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This is the health benefit Plan of the Person as it appears in the
|
||
source data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
plan_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data codes the Plan in an OMOP supported vocabulary store
|
||
the concept_id here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
sponsor_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field represents the sponsor of the Plan who finances the Plan.
|
||
This includes self-insured, small group health plan and large group
|
||
health plan.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Map the sponsor directly to a standard CONCEPT_ID. If one does not
|
||
exists please contact the vocabulary team. There is no global controlled
|
||
vocabulary available for this information. The point is to stratify on
|
||
this information and identify if Persons have the same sponsor though
|
||
the name of the sponsor is not necessary. <a
|
||
href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
sponsor_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Plan sponsor as it appears in the source data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
sponsor_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data codes the sponsor in an OMOP supported vocabulary
|
||
store the concept_id here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
family_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The common identifier for all people (often a family) that covered by
|
||
the same policy.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Often these are the common digits of the enrollment id of the policy
|
||
members.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
stop_reason_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
This field represents the reason the Person left the Plan, if known.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Map the stop reason directly to a standard CONCEPT_ID. If one does not
|
||
exists please contact the vocabulary team. There is no global controlled
|
||
vocabulary available for this information. <a
|
||
href="http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=">Accepted
|
||
Concepts</a>.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
stop_reason_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Plan stop reason as it appears in the source data.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
stop_reason_source_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
If the source data codes the stop reason in an OMOP supported vocabulary
|
||
store the concept_id here.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cost_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cost_event_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cost_domain_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(20)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
DOMAIN
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cost_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
currency_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
total_charge
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
total_cost
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
total_paid
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
paid_by_payer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
paid_by_patient
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
paid_patient_copay
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
paid_patient_coinsurance
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
paid_patient_deductible
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
paid_by_primary
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
paid_ingredient_cost
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
paid_dispensing_fee
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
payer_plan_period_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
amount_allowed
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
revenue_code_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
revenue_code_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Revenue codes are a method to charge for a class of procedures and
|
||
conditions in the U.S. hospital system.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(50)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drg_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drg_source_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Diagnosis Related Groups are US codes used to classify hospital cases
|
||
into one of approximately 500 groups.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(3)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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. Every record in the DRUG_EXPOSURE table should be
|
||
part of a drug era based on the dates of exposure.</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_era_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The drug_concept_id should conform to the concept class ‘ingredient’ as
|
||
the drug_era is an era of time where a person is exposed to a particular
|
||
drug ingredient.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Drug
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_era_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Drug Era Start Date is the start date of the first Drug Exposure for
|
||
a given ingredient, with at least 31 days since the previous exposure.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_era_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Drug Era End Date is the end date of the last Drug Exposure. The End
|
||
Date of each Drug Exposure is either taken from the field
|
||
drug_exposure_end_date or, as it is typically not available, inferred
|
||
using the following rules: For pharmacy prescription data, the date when
|
||
the drug was dispensed plus the number of days of supply are used to
|
||
extrapolate the End Date for the Drug Exposure. Depending on the
|
||
country-specific healthcare system, this supply information is either
|
||
explicitly provided in the day_supply field or inferred from package
|
||
size or similar information. For Procedure Drugs, usually the drug is
|
||
administered on a single date (i.e., the administration date). A
|
||
standard Persistence Window of 30 days (gap, slack) is permitted between
|
||
two subsequent such extrapolated DRUG_EXPOSURE records to be considered
|
||
to be merged into a single Drug Era.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_exposure_count
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The count of grouped DRUG_EXPOSURE records that were included in the
|
||
DRUG_ERA row
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
gap_days
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Gap Days determine how many total drug-free days are observed
|
||
between all Drug Exposure events that contribute to a DRUG_ERA record.
|
||
It is assumed that the drugs are “not stockpiled” by the patient,
|
||
i.e. that if a new drug prescription or refill is observed (a new
|
||
DRUG_EXPOSURE record is written), the remaining supply from the previous
|
||
events is abandoned. The difference between Persistence Window and Gap
|
||
Days is that the former is the maximum drug-free time allowed between
|
||
two subsequent DRUG_EXPOSURE records, while the latter is the sum of
|
||
actual drug-free days for the given Drug Era under the above assumption
|
||
of non-stockpiling.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
dose_era_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
drug_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Concept Id representing the specific drug ingredient.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Drug
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
unit_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Concept Id representing the unit of the specific drug ingredient.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Unit
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
dose_value
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The numeric value of the dosage of the drug_ingredient.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
float
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
dose_era_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date the Person started on the specific dosage, with at least 31
|
||
days since any prior exposure.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
dose_era_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date the Person was no longer exposed to the dosage of the specific
|
||
drug ingredient. An era is ended if there are 31 days or more between
|
||
dosage records.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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 and every Condition
|
||
Occurrence record should be part of a Condition Era. 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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_era_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
person_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
PERSON
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The Concept Id representing the Condition.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Condition
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_era_start_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The start date for the Condition Era constructed from the individual
|
||
instances of Condition Occurrences. It is the start date of the very
|
||
first chronologically recorded instance of the condition with at least
|
||
31 days since any prior record of the same Condition.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_era_end_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The end date for the Condition Era constructed from the individual
|
||
instances of Condition Occurrences. It is the end date of the final
|
||
continuously recorded instance of the Condition.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
condition_occurrence_count
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The number of individual Condition Occurrences used to construct the
|
||
condition era.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
metadata_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
metadata_type_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
name
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(250)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
value_as_string
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(250)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
value_as_concept_id
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
integer
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
CONCEPT
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
metadata_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
metadata_datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
datetime
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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>
|
||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||
<thead>
|
||
<tr>
|
||
<th style="text-align:left;">
|
||
CDM Field
|
||
</th>
|
||
<th style="text-align:left;">
|
||
User Guide
|
||
</th>
|
||
<th style="text-align:left;">
|
||
ETL Conventions
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Datatype
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Required
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Primary Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
Foreign Key
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Table
|
||
</th>
|
||
<th style="text-align:left;">
|
||
FK Domain
|
||
</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cdm_source_name
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The name of the CDM instance.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(255)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Yes
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cdm_source_abbreviation
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The abbreviation of the CDM instance.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(25)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cdm_holder
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The holder of the CDM instance.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(255)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
source_description
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The description of the CDM instance.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(MAX)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
source_documentation_reference
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(255)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cdm_etl_reference
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Version of the ETL script used. e.g. link to the Git release
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(255)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
source_release_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date the data was extracted from the source system. In some systems
|
||
that is the same as the date the ETL was run. Typically the latest even
|
||
date in the source is on the source_release_date.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cdm_release_date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
The date the ETL script was completed. Typically this is after the
|
||
source_release_date.
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
date
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
cdm_version
|
||
</td>
|
||
<td style="text-align:left;">
|
||
Version of the OMOP CDM used as string. e.g. v5.4
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(10)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td style="text-align:left;font-weight: bold;">
|
||
vocabulary_version
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
varchar(20)
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
No
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
<td style="text-align:left;">
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</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 standardized
|
||
analytics. Each Standard Concept belongs to one Domain, which defines
|
||
the location where the Concept would be expected to occur within the
|
||
data tables of the CDM. Concepts can represent broad categories
|
||
(like</p>
|
||
</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>
|